School District Incident Response Playbook

An effective K-12 incident response team must be assembled and documented before an incident occurs. In most school districts, the Technology Director or Director of Information Services serves as the Incident Commander, responsible for coordinating all technical response activities, making containment decisions, and serving as the primary liaison between the technical team and district leadership. This individual should have pre-delegated authority from the superintendent to take immediate containment actions — including disconnecting systems from the network — without waiting for administrative approval during active incidents.

The Communications Lead, typically the district's Public Information Officer or Communications Director, manages all internal and external messaging including parent notifications, media inquiries, and social media monitoring. Legal Counsel — whether in-house or a pre-retained firm with cybersecurity incident experience — advises on breach notification obligations, regulatory compliance, evidence preservation, and law enforcement engagement. The Human Resources Director is essential for incidents involving employee data or insider threats.

The Superintendent Notification Chain must be clearly defined with specific triggers for escalation. Level 1 incidents (ransomware, confirmed data breach) require immediate superintendent notification regardless of time of day, followed by board president notification within four hours. Level 2 incidents (active intrusion without confirmed data access) require superintendent notification within two hours during business hours. The superintendent should have a pre-briefed understanding of their role during cyber incidents: authorizing public communications, engaging insurance carriers, and supporting the Incident Commander's technical decisions.

Districts should also identify and pre-engage external resources including a digital forensics and incident response (DFIR) firm, cyber insurance carrier claims contacts, and FBI and MS-ISAC reporting contacts. These relationships should be documented in a contact card that is accessible offline — printed copies stored securely — since email and network-based documentation may be unavailable during an active incident.

A consistent incident classification system ensures appropriate resource allocation and escalation. This playbook defines four severity levels calibrated to K-12 operational impact.

Level 1 — Critical: Active ransomware encryption, confirmed exfiltration of student or staff PII, compromise of the Student Information System (SIS) or financial systems, or any incident that disrupts district-wide instructional operations. Level 1 incidents activate the full incident response team, trigger immediate superintendent and board notification, and authorize engagement of external DFIR and legal resources. Examples include ransomware spreading across file servers, a confirmed breach of PowerSchool or Infinite Campus data, or a BEC resulting in fraudulent wire transfer.

Level 2 — High: Confirmed unauthorized access to district systems without evidence of data exfiltration, malware infection contained to a limited number of endpoints, or compromise of staff email accounts. Level 2 incidents require Incident Commander engagement and superintendent notification within two business hours. Examples include a compromised administrator account with evidence of mailbox access, or malware detected on multiple endpoints in a single building.

Level 3 — Moderate: Isolated security events that indicate attempted but unsuccessful attacks, or successful attacks with minimal operational impact. Examples include a single employee clicking a phishing link and entering credentials (with password reset completed), a malware detection quarantined by endpoint protection, or a minor policy violation such as unauthorized software installation. Level 3 incidents are managed by the IT security team with Incident Commander notification.

Level 4 — Low: Security events that require logging and monitoring but no immediate response action. Examples include blocked phishing emails, firewall-blocked intrusion attempts, or vulnerability scan findings. Level 4 events are documented in the security log and reviewed during regular security operations meetings to identify trends that may indicate escalating threat activity.

Effective incident detection in K-12 environments relies on correlation of multiple signal sources. The iboss SASE platform provides centralized visibility across web traffic, cloud application usage, and network access — generating alerts for indicators of compromise including connections to known command-and-control infrastructure, anomalous data transfer volumes, impossible-travel authentication events, and policy violations such as attempts to access known malicious or newly registered domains.

When an alert fires or a user reports a suspected incident, the responding analyst should immediately document the initial indicators: the alert source, timestamp, affected user(s) and device(s), and the nature of the suspicious activity. This documentation begins the incident timeline, which becomes critical for forensic investigation and regulatory reporting. Use the Initial Assessment Checklist to ensure consistent triage.

• Record the date, time, and method of detection (automated alert, user report, third-party notification)
• Identify all known affected systems, users, and data repositories
• Determine whether the activity is ongoing or has concluded
• Assess initial scope: single device, single building, or district-wide
• Check iboss dashboards for correlated alerts across web gateway, CASB, and ZTNA
• Review authentication logs for the affected accounts — look for impossible travel, unusual hours, or access from unrecognized devices
• Determine if sensitive data repositories (SIS, financial systems, HR records) show evidence of access
• Assign initial severity classification (Level 1-4) and initiate appropriate notification chain
• Begin preserving volatile evidence — do not reboot affected systems until forensic guidance is obtained

Containment is the most time-sensitive phase of incident response. The objective is to prevent the threat from spreading to additional systems while preserving forensic evidence for investigation. Containment decisions often involve difficult tradeoffs between operational disruption and security — taking systems offline interrupts instruction, but delayed containment allows attackers to expand their access and exfiltrate additional data.

For ransomware incidents, immediate network isolation of affected segments is critical. If encryption is actively spreading, the Incident Commander should authorize disconnection of affected buildings or VLANs from the district backbone. If the scope is uncertain, isolating the district from the internet while maintaining internal connectivity may be appropriate to halt command-and-control communications without fully disrupting local operations. iboss ZTNA policies can be modified in real time to revoke access for compromised users or device groups without impacting the broader district.

Device-level quarantine should be implemented for any endpoint confirmed or suspected to be compromised. Do not power off affected machines — instead, disconnect them from the network (disable Wi-Fi, unplug Ethernet) to preserve volatile memory evidence that may be critical for forensic analysis. For cloud-based compromises involving Google Workspace or Microsoft 365, immediately revoke active sessions and OAuth tokens for affected accounts, reset passwords, and review audit logs for data access and sharing activity.

Implement a communications hold during active containment: restrict discussion of the incident to the incident response team using out-of-band communication channels (phone calls, a pre-established Signal group, or personal email). District email and messaging systems may be compromised and should not be used for sensitive incident communications. Instruct all staff who become aware of the incident to refrain from posting on social media or discussing details outside the IR team.

Eradication begins only after containment is confirmed and the scope of compromise is reasonably understood. Premature eradication — such as reimaging a single infected machine without understanding how the attacker gained access — frequently results in reinfection because the root cause and persistence mechanisms remain in place.

For malware and ransomware incidents, eradication involves identifying and removing all attacker artifacts: malware binaries, scheduled tasks, registry modifications, unauthorized user accounts, web shells, and any persistence mechanisms. In K-12 environments with standardized device images, reimaging affected endpoints from known-clean golden images is often more reliable and faster than attempting manual malware removal. Ensure the golden image itself has been verified as uncompromised before using it for restoration.

Credential reset is essential and must be comprehensive. At minimum, reset passwords for all accounts with any evidence of compromise. For Level 1 incidents, conduct a district-wide password reset for all accounts including service accounts, local administrator accounts, and the KRBTGT account (if Active Directory is in use) to invalidate any Kerberos tickets the attacker may have forged. Review and revoke all OAuth application consents and API tokens that were granted during the compromise period.

Vulnerability remediation must address the initial access vector before systems are reconnected. If the attacker exploited an unpatched VPN appliance, that appliance must be patched — or preferably replaced with ZTNA — before network access is restored. If the entry point was a phishing email, verify that email filtering rules have been updated, the malicious sender domain has been blocked, and any users who interacted with the phishing message have been identified and their credentials reset. Document all eradication actions taken for inclusion in the post-incident report.

Recovery priorities for school districts must align with instructional and operational necessities. The restoration sequence should be pre-determined and documented, then adjusted as needed based on the specific incident. The recommended priority order for K-12 system restoration is as follows.

Tier 1 — Restore within 24 hours: Student Information System (SIS), district email and communication platforms, and network authentication services (Active Directory or cloud identity provider). These systems are essential for school operations, student safety (attendance and emergency contact data), and incident response team communications. Tier 2 — Restore within 48-72 hours: Learning management systems, instructional applications, staff HR and payroll systems, and phone/VoIP systems. Tier 3 — Restore within one week: Non-critical administrative applications, archived data, and ancillary services.

Restoration should follow a phased reconnection approach. Bring each system online in an isolated network segment first, verify clean operation and monitor for indicators of reinfection for a minimum of 24 hours, then reconnect to the production network. iboss SASE policies should be configured with heightened monitoring thresholds during the recovery period to detect any attacker activity that may have survived eradication efforts.

Backup integrity is critical. Before restoring from backups, verify that backup data predates the initial compromise. If the attacker maintained access for weeks or months before deploying ransomware (a common tactic), recent backups may contain compromised configurations or backdoors. Work with the DFIR team to establish the earliest known date of compromise and select backup restore points accordingly. Test restored data in an isolated environment before deploying to production.

The post-incident phase is where institutional learning occurs and legal and regulatory obligations are fulfilled. Schedule a formal lessons-learned meeting within two weeks of incident resolution while details are fresh. Include all IR team members and relevant stakeholders. The meeting should produce a written after-action report documenting the complete incident timeline, root cause analysis, what worked well in the response, what needs improvement, and specific action items with assigned owners and deadlines.

Board notification is a governance obligation that should be handled carefully. Prepare a board briefing that includes: a factual summary of the incident without excessive technical detail, the impact on students and staff, the response actions taken, the current status of remediation, any legal or regulatory notifications required, estimated financial impact, and recommended security investments to prevent recurrence. Work with legal counsel to determine whether the briefing should occur in executive session given potential litigation implications.

Insurance claim documentation should be assembled throughout the incident response process, not retroactively. Cyber insurance carriers require detailed documentation including the incident timeline, forensic investigation reports, remediation costs, legal fees, notification costs, and any ransom payments. Notify your cyber insurance carrier as early as possible — many policies require notification within 24-72 hours of discovery, and late notification can jeopardize coverage.

Law enforcement coordination serves both the district's interests and the broader K-12 community. File a report with the FBI Internet Crime Complaint Center (IC3) for any incident involving financial loss, data theft, or ransomware. Report to MS-ISAC (Multi-State Information Sharing and Analysis Center) to contribute threat intelligence that helps protect other school districts. Neither FBI nor MS-ISAC reporting is mandatory for most districts, but both organizations provide valuable investigative support and threat intelligence sharing that can assist with attribution and recovery.

Pre-drafted communication templates dramatically reduce response time and ensure consistent, legally reviewed messaging during high-stress incident situations. All templates should be reviewed by legal counsel annually and after any significant incident. The following templates should be maintained and accessible offline.

The Parent/Guardian Notification Letter should include: a factual description of the incident in plain language, the types of data potentially affected, the steps the district has taken in response, any protective actions families should take (such as monitoring credit reports), contact information for questions, and information about any credit monitoring or identity protection services being offered. Avoid speculative language, do not assign blame, and do not characterize the severity in ways that may later prove inaccurate.

The Staff Notification should be distributed through a verified communication channel (not the potentially compromised email system) and include: a description of the incident, any immediate actions staff must take (such as password resets), guidance on what information is appropriate to share with parents and students (answer: refer all questions to the communications lead), and the expected timeline for system restoration.

The Media Statement should be brief, factual, and consistent with the parent notification. Designate a single spokesperson. Acknowledge the incident, affirm that the district is working with cybersecurity experts and law enforcement, emphasize the district's commitment to protecting student and staff data, and provide a timeline for further updates. Do not disclose technical details that could assist the attacker or compromise the investigation.

The Board Briefing Outline should follow a structured format: incident summary (what happened), impact assessment (who is affected), response actions (what was done), current status, legal and regulatory obligations, financial impact estimate, and recommended next steps including security investments.