Incident Response Policy

How School-Core detects, escalates, and notifies Customers of security incidents.

Effective May 1, 2026 · v1.0 — June 2026

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

LevelDescriptionExamplesResponse Time
P1 — CriticalActive data breach, unauthorized access to PII, system compromiseDatabase exfiltration, ransomware, credential theftImmediate (within 1 hour)
P2 — HighPotential breach, vulnerability actively exploitedSuspicious access patterns, unpatched critical CVEWithin 4 hours
P3 — MediumSecurity weakness discovered, no active exploitationFailed brute-force attempts, misconfiguration foundWithin 24 hours
P4 — LowMinor security concern, informationalPhishing attempt, policy violationWithin 72 hours

Incident Response Team

RoleResponsibility
Incident CommanderLeads response, makes decisions, coordinates communication
Technical LeadInvestigates technical aspects, implements containment
Communications LeadManages notifications to schools, parents, regulators
Legal/ComplianceAdvises on regulatory obligations, manages documentation
Executive SponsorFinal 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:

  1. Acknowledge the alert and assess initial severity
  2. Assign an Incident Commander
  3. Create an incident record with timestamp, reporter, and initial assessment
  4. 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

ContactDetails
Security Teamsecurity@school-core.com
Privacy Officerprivacy@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

VersionDateChanges
1.0March 2026Initial plan
1.1May 2026No 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