School IT incident response: prepare the first decisions

Define what starts the plan

An incident does not have to begin with a ransom message. A lost device containing school information, unexpected administrator access, unusual account activity or a widespread system failure can all need coordinated attention. Give staff a simple reporting route and examples they can recognise without having to diagnose the cause.

Distinguish technical faults from potential security incidents while allowing uncertainty. The first report may be incomplete. Staff should be able to say that something seems wrong without proving an attack has happened. A prompt, calm report gives the response team more options.

The National Cyber Security Centre recommends preparing incident response processes before they are needed. For a school, the plan must join technical work with decisions about attendance, safeguarding, staff instructions and parent communication. It should be usable during a busy school morning, not only in a policy review.

Keep a short activation page

The first page should identify the school incident lead, technical lead, deputies and alternative contact methods. Include the people responsible for safeguarding, data protection, communications and operational decisions. Keep an accessible copy outside the systems that may fail, with appropriate control over sensitive contact information.

Record how to reach the IT provider, relevant trust or local authority support, insurers and specialist advisers where applicable. Check any contractual notification requirements in advance. Do not assume that the usual supplier ticket portal will be available during an identity-system outage.

List who can authorise emergency expenditure, temporary service restrictions and public messages. Those decisions become harder if they depend on a single unavailable person.

Establish what is known

Open an incident record with the time, reporter, symptoms, affected services and actions already taken. Separate confirmed facts from assumptions. Record decisions and their owners so the school can understand later why a service was disconnected or a message sent.

Ask staff to preserve relevant messages and report what they observed. Avoid speculative instructions to delete files, reinstall devices or reboot everything. Technical responders should decide how to contain the issue while considering evidence and continuity. If a device appears compromised, staff should contact the designated response route promptly and follow the agreed procedure.

Do not use a potentially compromised communication channel to exchange recovery credentials or sensitive investigation details. The response plan should specify a known alternative, rather than improvising with personal accounts across the school.

Keep essential school operations safe

The incident lead should establish which services are unavailable and what the school can safely continue. Safeguarding and operational leaders need to assess the consequences, particularly where emergency contacts, registers, access systems or telephones are affected.

Use pre-agreed manual arrangements where appropriate. Record new information securely and identify who will reconcile it when systems return. Avoid creating uncontrolled copies of entire databases in response to pressure. A temporary workaround should have an owner, purpose and end point.

Keep staff instructions short and consistent. Explain what is unavailable, which actions they should avoid, where to report new symptoms and when the next update will arrive. Honest uncertainty is preferable to a confident restoration time that the technical team has not supported.

Handle reporting and communications deliberately

Involve the data protection lead promptly if personal information may be affected. They should assess applicable notification duties and timescales using current guidance and the facts of the incident. Do not delay that assessment while waiting for every technical detail, and do not assume every outage is automatically a reportable personal data breach.

Agree who speaks to families, staff and external organisations. Messages should focus on practical effects and required actions without exposing security-sensitive details or making unsupported claims that no data was affected. Keep a record of what was communicated and when.

Recover in a controlled order

Technical responders should establish a safe recovery sequence and confirm that the cause or active access has been addressed. Restoring data while an attacker still has access can repeat the problem. Service owners need to validate restored information and functions before normal use resumes.

Prioritise agreed critical services and communicate limitations. Check how work completed during the outage will be reconciled, including transactions and records changed manually. Use the backup and recovery guide to prepare this in advance.

After immediate recovery, hold a proportionate review. Identify what helped, what delayed decisions and which controls or contracts need changing. Assign actions without turning the exercise into blame. Rehearse the revised plan with a short tabletop scenario so the next response depends less on memory and more on an understood process.