Incident Response Runbook

1. Purpose

This runbook tells the SoloCogs operator exactly what to do when a security incident is suspected, confirmed, or reported. It is written to be followed under pressure, with the most time-critical steps first. The 72-hour ICO notification clock starts at the moment the operator becomes aware of a personal data breach (UK GDPR Article 33), so step zero is always "start a timer."

2. What counts as an "incident"

• Personal data breach - any event that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data we hold. Examples: an attacker reads a student's progress data; a misconfigured RLS policy lets parents see another family's records; a backup tape is lost.
• Account compromise - any sign that a parent's, student's, tutor's, school admin's, or platform admin's credentials have been stolen or guessed.
• System outage - the platform is wholly or partly unavailable. Not necessarily a breach, but logged here so the timeline is preserved if it turns out to be one.
• Suspected attack - unusual traffic patterns, repeated 4xx auth failures, surfaced XSS or injection attempts in logs.
• Lost or stolen device - laptop, phone, USB drive containing platform data or credentials.
• Third-party incident - Supabase, Google, PayPal, Wonde, or any other sub-processor reports a breach affecting SoloCogs data.
• Safeguarding-flagged content - if the incident relates to a disclosure of harm to a child it is ALSO handled under the Safeguarding Policy and the DSL takes the lead.

3. Severity classification

Severity	Examples	Initial response time
P0 - critical	Confirmed exposure of children's data; live attack in progress; safeguarding disclosure	Within 1 hour, day or night
P1 - high	Suspected breach (high risk); admin account compromise; major outage	Within 4 hours
P2 - medium	Single non-admin account compromise; partial outage; subprocessor breach announcement	Within 24 hours
P3 - low	Suspected probe / scan; misconfiguration with no observed exposure	Within 72 hours

4. Phase A - First hour (always)

1. Start the incident timer. Record the exact UTC time and the exact moment the operator became aware. This timestamp is what the 72-hour ICO clock counts from.
2. Open an incident note. Keep a plain text file at incidents/YYYY-MM-DD-short-title.md. Record every action with a timestamp. Do not rely on memory.
3. Contain. Stop the bleeding before investigating further:
   • Compromised admin account → immediately revoke its sessions in Supabase Auth, rotate its password, force MFA re-enrolment.
   • Compromised secret (service-role key, Wonde token, Gemini key) → rotate the key now in the relevant provider's dashboard; restart any function that reads it.
   • Live attack → put the site behind a Cloudflare "Under Attack" challenge or take it offline; revoke any anon access being abused.
   • Data exposure via misconfigured RLS → revoke the policy or take the affected table offline until fixed.
4. Classify severity (see Section 3). If P0 or P1, proceed to Phase B without delay. If P2 or P3, Phase B can wait for normal working hours.
5. Snapshot evidence. Capture logs (Supabase function logs, auth logs, RLS denial logs), any relevant browser screenshots, and a copy of the schema before any further changes. These may be needed for the ICO and any law-enforcement referral.

5. Phase B - First 24 hours

1. Identify scope. Which users, which categories of data, which time window? Answer in the incident note.
2. Identify cause. Vulnerability, misconfiguration, credential leak, third-party compromise, lost device, internal mistake, deliberate insider action?
3. Assess risk to data subjects. Is the data likely to result in a risk to people's rights and freedoms? For children's data, the bar for "likely to result in a high risk" is lower than for adults' data. Document the reasoning.
4. Decide on notifications.
   • ICO - notify within 72 hours of awareness IF the breach is likely to result in a risk to the rights and freedoms of natural persons (UK GDPR Article 33). Use ico.org.uk/for-organisations/report-a-breach/ or call 0303 123 1113. If unsure, notify - the ICO does not penalise over-reporting.
   • Affected data subjects - notify "without undue delay" IF the risk is HIGH (Article 34). For children's data this threshold is reached quickly. Use the template in Section 8.
   • Schools (where applicable) - if the affected data came from a school via Wonde or a school sign-up, notify the school's DPO; they have their own KCSiE reporting obligations.
   • Action Fraud / NCA - if criminal action is suspected, report to Action Fraud on 0300 123 2040.
5. Fix the root cause. Patch the vulnerable code path, tighten the RLS policy, rotate the leaked secret, or whatever closes the door. Do not consider the incident closed until the fix is shipped and verified.

6. Phase C - Within one week: recovery + lessons learned

1. Restore service safely. Bring affected systems back only after the fix is in place, the data integrity is verified, and access logs have been reviewed for any further damage.
2. Post-incident review. Write a one-page review in the incident note covering: what happened, what we did well, what we did badly, what we will change. Schools and the ICO may request this.
3. Update controls. If the incident exposed a gap in RLS, monitoring, secrets-handling, or staff training, ship the fix to that gap as a permanent change - not just the immediate symptom.
4. Close the incident. Mark the incident note "closed", with the final timeline. Keep all incident notes indefinitely as part of the accountability record.

7. Key contacts

• Data Protection Lead / Operator - Jazz, hello@solocogs.co.uk
• Designated Safeguarding Lead - Jazz (see Safeguarding Policy)
• ICO (Information Commissioner's Office) - ico.org.uk - 0303 123 1113 - breach report at ico.org.uk/for-organisations/report-a-breach/
• Action Fraud (criminal cyber) - actionfraud.police.uk - 0300 123 2040
• NSPCC Helpline (for child safeguarding incidents that surface during a security incident) - 0808 800 5000
• Supabase support (for platform-side incidents) - via the Supabase dashboard support form, or support@supabase.com

8. Notification template - affected users

Use this template, adapted to the specifics of the incident, when notifying affected parents, students, or schools. Keep it short, factual, and free of jargon. Do not delay sending while polishing the wording - send the first communication within 72 hours and follow up with detail.

Subject: Important: information about your SoloCogs account

Dear [name],

We are writing to let you know that on [date] we identified [a one-sentence description of what happened, in plain English]. This affected [what data, whose data].

We have already [containment action taken] and [fix shipped / underway].

The risk to you / your child is [your honest assessment - low / medium / high - and why]. To be safe, we recommend you [specific action: change password, watch for phishing, etc.].

We have also reported this incident to the Information Commissioner's Office. You have the right to lodge a complaint with the ICO at ico.org.uk if you are concerned.

If you have questions, please reply to this email or contact us at hello@solocogs.co.uk. We are sorry this has happened and we are taking it seriously.

- The SoloCogs team

9. Review

This runbook is reviewed at least annually, and immediately after any P0 or P1 incident. The version number and review date at the top of this page are updated each review cycle.