Purpose
This Incident Response Plan (IRP) establishes procedures for identifying, containing, investigating, and recovering from security incidents affecting the School-Core platform. Given that we process sensitive data of minors, staff, and educational institutions, our response procedures prioritize rapid containment and transparent communication.
Scope
This plan applies to all security incidents involving:
- Unauthorized access to student, staff, or parent data
- Data breaches (confirmed or suspected)
- System compromises (malware, ransomware, unauthorized modifications)
- Denial-of-service attacks affecting platform availability
- Insider threats (unauthorized access by employees or contractors)
- Third-party/sub-processor security incidents
- Loss or theft of devices containing platform credentials
Incident Severity Levels
| Level | Description | Examples | Response Time |
|---|---|---|---|
| P1 — Critical | Active data breach, unauthorized access to PII, system compromise | Database exfiltration, ransomware, credential theft | Immediate (within 1 hour) |
| P2 — High | Potential breach, vulnerability actively exploited | Suspicious access patterns, unpatched critical CVE | Within 4 hours |
| P3 — Medium | Security weakness discovered, no active exploitation | Failed brute-force attempts, misconfiguration found | Within 24 hours |
| P4 — Low | Minor security concern, informational | Phishing attempt, policy violation | Within 72 hours |
Incident Response Team
| Role | Responsibility |
|---|---|
| Incident Commander | Leads response, makes decisions, coordinates communication |
| Technical Lead | Investigates technical aspects, implements containment |
| Communications Lead | Manages notifications to schools, parents, regulators |
| Legal/Compliance | Advises on regulatory obligations, manages documentation |
| Executive Sponsor | Final authority on business-impacting decisions |
Response Phases
Phase 1: Detection & Identification (0–1 hour)
Triggers:
- Automated alerts from monitoring systems (Sentry, audit logs)
- User reports of suspicious activity
- Third-party notification (sub-processor breach, security researcher)
- Internal discovery during routine review
Actions:
- Acknowledge the alert and assess initial severity
- Assign an Incident Commander
- Create an incident record with timestamp, reporter, and initial assessment
- Begin evidence preservation (logs, screenshots, access records)
Phase 2: Containment (1–4 hours)
Immediate containment:
- Revoke compromised credentials
- Isolate affected systems or tenant(s)
- Block suspicious IP addresses
- Disable compromised accounts
- Rotate API keys and secrets if exposed
Short-term containment:
- Deploy emergency patches
- Implement additional monitoring
- Restrict access to affected data
Phase 3: Investigation (4–48 hours)
Analysis:
- Review audit logs for affected tenant(s)
- Identify scope: which tenants, users, and data types are affected
- Determine attack vector and timeline
- Identify root cause
- Assess whether data was accessed, modified, or exfiltrated
Evidence collection:
- Preserve all relevant audit logs
- Document database query logs
- Capture network access logs
- Record all response actions taken
Phase 4: Notification (within 72 hours of confirmation)
Regulatory notification:
- GDPR: Notify supervisory authority within 72 hours of awareness
- FERPA: Notify affected educational institutions immediately
- State breach laws: Follow applicable state notification requirements
- COPPA: Notify FTC if children's data is involved
School notification (within 24 hours):
- Email to school administrators and designated privacy contact
- Include: nature of incident, data affected, containment steps taken, remediation timeline
- Provide guidance for affected individuals
Parent notification (when required):
- Via school's preferred communication channel
- Clear, non-technical language
- Include: what happened, what data was affected, what we're doing, what they should do
Phase 5: Eradication & Recovery (48 hours – 2 weeks)
Eradication:
- Remove malware, backdoors, or unauthorized access methods
- Patch vulnerabilities that were exploited
- Reset all potentially compromised credentials
- Verify clean state of all affected systems
Recovery:
- Restore services from clean backups if needed
- Implement additional security controls
- Verify all systems are functioning normally
- Resume normal operations
Phase 6: Post-Incident Review (within 2 weeks)
Lessons learned:
- Conduct post-incident review with all team members
- Document timeline, actions taken, and outcomes
- Identify gaps in detection, response, or prevention
- Update this IRP based on findings
- Implement preventive measures
Documentation:
- Complete incident report
- Update risk register
- File regulatory compliance documentation
- Retain all incident records for 3 years
Communication Templates
School Administrator Notification
Subject: Security Incident Notification — [Incident ID]
Dear [Administrator Name],
We are writing to inform you of a security incident that may affect [School Name]'s data on the School-Core platform.
What happened: [Brief description] When: [Date/time of discovery] What data may be affected: [Categories of data] What we have done: [Containment and investigation steps] What you should do: [Recommended actions] Next steps: We will provide updates as our investigation progresses.
For questions, contact our security team at security@school-core.com.
Regulatory Authority Notification
[Template for GDPR Article 33 notification, including: nature of breach, categories/approximate number of data subjects affected, name and contact details of DPO, likely consequences, measures taken or proposed]
Contact Information
| Contact | Details |
|---|---|
| Security Team | security@school-core.com |
| Privacy Officer | privacy@school-core.com |
| Emergency Hotline | [To be established] |
Plan Testing
This incident response plan is tested through:
- Tabletop exercises: Quarterly scenario-based discussions
- Simulation drills: Annual simulated incident response
- Plan review: Semi-annual review and update of procedures
- Training: Annual security awareness training for all team members
Revision History
| Version | Date | Changes |
|---|---|---|
| 1.0 | March 2026 | Initial plan |
| 1.1 | May 2026 | No incident-response changes; bumped to align effective dates with Privacy / Terms / Security / DPA refresh covering audit-log expansion, role-count corrections (47 vs 24), Cloud Drive on R2, and the platform-tenant model |
Last updated: June 2026 · v1.0 — June 2026