Most schools discover the state of their incident plan on the morning they need it. This is what the first hour looks like, who has to decide what, and the handful of things worth settling in advance — because the plan you have not read is the plan you do not have.
The first hour
1. Contain, before you understand
You will not know what has happened for some time. That is normal, and waiting to understand before acting is how a bad morning becomes a bad fortnight. Disconnect the affected machines from the network — unplug the cable, turn off the Wi-Fi — and leave them switched on. Powering down destroys evidence sitting in memory that an investigator would want.
2. Start a written log
A notebook is fine. Every action, who took it, and the time. You are not writing it for yourself: you are writing it for the insurer who asks what you did and when, for the ICO if the incident turns out to be reportable, and for the person who picks this up at 6pm when you have gone home. Nobody has ever regretted the log.
3. Ring the people who can act
Your IT provider, the headteacher or the trust’s executive lead, and your data protection officer. If your response plan has a contact list, this is the moment it either works or turns out to be three years old.
Who decides what
An incident produces a run of decisions in a short time, and the arguments happen because nobody agreed in advance who owns which one. Settle these while nothing is wrong:
- Who declares an incident. Somebody has to say the word, and it should be a named role rather than whoever happens to be in the building.
- Who can take systems offline. Taking the network down in the middle of the school day is a real decision with real consequences, and the person who has to make it at 9am should already know it is theirs.
- Who speaks to parents, and who speaks to the press. One voice. Agreed before, not drafted during.
- Who decides whether it is reportable. The school is the data controller. Not the IT provider, and not a supplier who was breached — see below.
The 72-hour clock, and what it actually says
Under UK GDPR Article 33, a personal data breach that is likely to result in a risk to people’s rights and freedoms must be reported to the ICO without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Three things about that sentence are routinely misread:
- It is 72 hours, not three working days. A Friday afternoon does not stop the clock.
- It starts when the school becomes aware — which is not necessarily when the attack began, and not when the investigation finishes.
- Not every incident is reportable. A ransomware attack on a system holding no personal data may not be. That judgement is the school’s, on the facts, and nobody outside the school can make it for you.
If a supplier holding your data is breached, the school is still the controller and the clock starts when the school is told. That surprises people, and it is the single most common gap this comes up against.
Who to tell, beyond the ICO
- Report Fraud — the national reporting service, at reportfraud.police.uk or 0300 123 2040, for England, Wales and Northern Ireland. Scotland reports to Police Scotland on 101. It replaced the previous national reporting service in December 2025, so a bookmark or a policy document naming the old one needs updating. The crime reference it gives you is what your insurer will ask for.
- The DfE, where the incident affects the running of the school.
- Your insurer — usually within a window set by the policy, which is often much shorter than you expect. Read it before you need it.
- The people affected, where the risk to them is high. That is a separate test from the ICO one, and a harder one.
Ransomware, specifically
The NCSC’s position is that paying does not guarantee your data back, does not stop it being published, and funds the next attack. It is not illegal to pay in the UK, but it should never be the plan, and a governing body that has never discussed it will be discussing it for the first time under the worst possible conditions.
What decides the outcome is almost always the backup: whether one exists that an attacker with full control of your network could not also encrypt, and whether anyone has performed a real restore from it in the last year. A backup nobody has tested is a belief, not a backup.
Rehearse it before September
A plan that has never been walked through fails in predictable places: the contact list is stale, two people think the other one calls the insurer, and nobody can find the document. An hour round a table with a scenario and the plan open finds all three, and the finding is the point — a rehearsal that goes smoothly has usually not been hard enough.
The NCSC publishes Exercise in a Box free, and it is good. There is no statutory rehearsal frequency for schools, so anyone quoting you one has invented it. Once a year, with the people who would actually be in the room, is a defensible answer.
What governors should expect to see
Not a technical report. A governing body needs to know that a plan exists, that it names people rather than roles nobody fills, that it has been rehearsed within the year, and that the school knows which of the four reporting routes apply to it. The questions a governing body should be asking cover this ground in full, and the school cyber security checklist turns it into work you can hand to somebody.