Incident Response Plan
How we detect, respond to, and recover from security and privacy incidents, and how we notify schools.
- Document owner: Oscar Ramos
- Approved by: Eli Johnson, Product Manager
- Version: 1.0
- Approved date: 9/21/2026
- Next review: 9/21/2027
- Applies to: Founders, Co-Founders, Designers, Head of Education Partnerships, and Software Developers
1. Purpose
To provide a clear, repeatable process for detecting, responding to, and recovering from security and privacy incidents — including breaches involving student education records — and for notifying our customer schools so they can meet their obligations to students and families. Supports SOC 2 and our FERPA commitments.
2. What counts as an incident
A security or privacy incident is any actual or suspected event that threatens the confidentiality, integrity, or availability of Ladderly Learning systems or data. Examples:
- Unauthorized access to, or exposure of, student data.
- Lost or stolen laptop/phone with access to company data.
- Malware, ransomware, or account compromise (e.g., phished credentials).
- Misconfiguration exposing data (e.g., a public cloud bucket, wrong recipient on an export).
- Vendor/subprocessor breach affecting our data.
A data breach is an incident confirmed to involve unauthorized access to or disclosure of protected data (including student PII).
If you see something, say something. Report immediately — do not investigate alone, and do not try to hide or fix it quietly. Early reporting is never penalized.
3. How to report
Report suspected incidents immediately to: Security officer over slack. Include what you saw, when, and any systems or data possibly involved. Preserve evidence — don’t delete anything.
4. Incident response team (IRT) and roles
| Role | Who | Responsibility |
|---|---|---|
| Incident Lead/Security Officer | Oscar Ramos | Runs the response, makes containment/escalation calls |
| Technical Lead | Chad Bell | Investigation, containment, eradication, recovery |
| Communications / Customer Lead | J Hathaway | Notifies affected schools; manages external messaging |
| Scribe | Oscar Ramos | Maintains the incident timeline and record |
5. Severity levels
| Level | Definition | Example |
|---|---|---|
| SEV-1 Critical | Confirmed breach of student data, or major outage | Student records exposed publicly |
| SEV-2 High | Likely breach or significant risk | Compromised admin account, unclear data impact |
| SEV-3 Medium | Contained event, limited/no data impact | Single phished account caught quickly, MFA held |
| SEV-4 Low | Minor, no data risk | Spam/phishing reported, no click |
Severity sets urgency and who gets pulled in. When unsure, treat it as higher severity until proven otherwise.
6. Response process (six phases)
1. Detect & report. Someone or something flags a possible incident; it’s reported to the security contact and logged with a timestamp.
2. Triage & activate. The Incident Lead confirms it’s a real incident, assigns a severity, opens an incident record.
3. Contain. Stop the bleeding: isolate affected systems, disable compromised accounts, revoke exposed credentials/keys, block malicious access — while preserving evidence (snapshots, logs) for investigation.
4. Eradicate & investigate. Find and remove the root cause (malware, misconfiguration, stolen credential). Determine what data was affected, whose, how much, and whether student records were involved.
5. Recover. Restore systems safely from clean backups, verify integrity, confirm the threat is gone, and return to normal operations with heightened monitoring.
6. Notify. Execute the notification procedure in Section 7 based on what the investigation found.
7. FERPA breach-notification procedure
Important: FERPA has no fixed “notify within X days” rule for vendors. Our policy is to notify the affected district within 48 hours of confirming an incident. The strictest applicable timeline always governs., our job is to tell the district promptly so they can meet their own duties to families.
Step 1 — Determine scope. Confirm whether student education records / PII were accessed or disclosed without authorization, and identify which schools’ data and roughly how many records/individuals are affected.
Step 2 — Check timelines. For each affected school, pull its DPA and note the required notification window and method (within 72hrs). The strictest applicable timeline governs. Where no timeline is specified, notify without unreasonable delay.
Step 3 — Notify each affected school. The Communications/Customer Lead notifies the school’s designated contact. Provide, to the extent known and without further exposing data: what happened, when it was discovered, the types of data involved, the schools/individuals affected, what we’ve done to contain it, and what we recommend. Send follow-ups as facts develop.
The school, as the educational agency/institution, is generally responsible for notifying parents and eligible students. We support that: providing accurate details, helping identify affected individuals, and cooperating with the school’s response. We do not notify parents/students directly unless the school directs us to or our contract requires it.
Step 4 — Record the disclosure. Document the breach and notifications in the incident record. FERPA requires the educational institution to keep a record of certain disclosures; support the school’s recordkeeping as needed.
Step 6 — Regulators / others. With Legal, determine whether any regulator, cyber-insurer, or law enforcement should be notified.
8. Post-incident review
Within 10 business days of closing a SEV-1 or SEV-2, the IRT holds a post-incident (after-action) review: what happened, timeline, root cause, what worked, what didn’t, and concrete corrective actions with owners and due dates. This is blameless — the goal is prevention. File the report and track the actions to completion.
9. Records
All incidents are logged with: date/time detected and resolved, severity, description, systems/data affected, actions taken, notifications made, and post-incident actions. Records are retained per the Data Retention & Disposal Policy.
11. Review
Reviewed and re-approved at least annually and after any major incident.