Incident response plan

← Back to Security

1. Purpose

This plan sets out how Edsthetic detects, responds to, contains, and recovers from security incidents affecting school, staff, or student data held in Writeiq and Allocateiq. It supports Edsthetic's obligations to schools under the Data Processing Agreement and to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act 1988).

2. Scope

A security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of school data. This includes:

• Unauthorised access to school_data, admin_schools, or licences tables
• Credential compromise (licence keys, admin PINs, staff PINs, Supabase service keys, Anthropic API keys)
• Loss of data through accidental deletion or corruption
• Denial-of-service affecting any product
• Suspected or confirmed data exfiltration
• Breach or misuse by a subprocessor (Supabase, Anthropic, Netlify, PostHog, Sentry)
• Vulnerabilities disclosed by security researchers through responsible disclosure

3. Severity classification

Severity	Definition	Examples
P1 — Critical	Confirmed breach of student data, or complete service outage	Unauthorised export of submission data; production database deleted
P2 — High	Credential compromise, suspected breach, or single-school outage	Service key rotated under suspicion; one school unable to log in for over 30 minutes
P3 — Medium	Vulnerability without confirmed exploitation, or degraded service	CSP bypass found in staging; rate limit exhaustion causing slow marking
P4 — Low	Informational, researcher disclosure, or contained anomaly	Security researcher reports non-exploitable finding; one teacher reports unusual but benign behaviour

4. Response team

For Edsthetic's current size, the response team is:

• Incident Lead: Ashwin Pillai (co-founder, deputy principal at Sacred Heart College Geelong)
• Technical Lead: Ashwin Pillai (primary developer on Writeiq and Allocateiq)
• Pedagogical Advisor: Mikhaila Picone (co-founder, GRR engine architect) — consulted on incidents affecting educational content or the lesson-plan engine
• External advisors: legal counsel (to be retained as part of the commercial launch preparation)

As Edsthetic grows, the team expands to dedicated Incident, Technical, and Communications leads.

5. Detection

Edsthetic monitors the following channels for incident indicators:

• Sentry: error rate alerts on all four projects (marketing site, Writeiq, Allocateiq, admin)
• Supabase dashboard: auth failure rate, RLS-denied read attempts, edge function error rate
• PostHog funnel dashboards: abnormal drop-off or spike in activity
• admin_alerts table: AI cost cap breach alerts at 50%, 80%, 100% thresholds; school-deletion audit entries
• Email inbox: hello@edsthetic.com.au for school reports and researcher disclosures
• Subprocessor status pages: Supabase, Anthropic, Netlify, PostHog, Sentry

All Edsthetic staff and school coordinators are encouraged to report anything unusual immediately to hello@edsthetic.com.au. No concern is too small.

6. Response workflow

6.1 Acknowledge (within 2 hours of detection)

• Incident Lead acknowledges the report or alert in writing
• Severity tier assigned using Section 3
• Initial scope noted (which school(s), which data, which systems)
• Incident reference number assigned (EDS-INC-YYYY-NNNN)

6.2 Contain (within 4 hours of P1/P2 incidents)

Containment is always the first priority. Specific actions depend on the incident class:

• Credential compromise: rotate the affected credential; revoke old sessions; force PIN changes where relevant
• Unauthorised access: revoke the attacker's access path, set RLS policies to deny-all on affected tables if required, take the product into read-only mode while root cause is investigated
• Subprocessor compromise: suspend traffic to the affected subprocessor; switch to fallback where available; communicate with subprocessor's security team
• Data corruption: switch affected product to read-only; initiate point-in-time restore to a separate environment for forensic review before touching the live database
• Denial-of-service: tighten rate limits via rate_limits table; engage Netlify's DDoS protection; identify and block attacker IP ranges

6.3 Investigate (begin within 4 hours, complete within 7 days for P1/P2)

• Collect logs: Sentry traces, Supabase logs, edge function logs, PostHog events, admin_alerts entries
• Identify root cause: code, configuration, credential theft, insider action, subprocessor, or user error
• Scope confirmation: which schools, which data, how many students affected, what was actually read or modified
• Document the timeline: detection, containment, investigation, resolution

6.4 Notify

Notification requirements depend on severity and legal obligation.

Affected schools:

• P1 or P2 incidents involving confirmed access to student data: notify the school's registered coordinator within 24 hours of confirmation
• P2 credential-compromise events: notify affected schools within 48 hours
• P3/P4: notify in a batched monthly security summary unless the school is directly affected

Office of the Australian Information Commissioner (OAIC):

• Where an incident meets the threshold of a Notifiable Data Breach (Part IIIC of the Privacy Act 1988) — likely to result in serious harm, and Edsthetic cannot take remedial action that prevents that harm — Edsthetic notifies the OAIC and all affected individuals as soon as practicable, within 30 days at the latest

Other subprocessors and regulators:

• If an incident originates with a subprocessor, that subprocessor's incident-notification clauses in our DPA apply in reverse
• Under Victorian state law, incidents affecting Victorian government schools may trigger additional notification to the Department of Education; schools are responsible for their own sector notification obligations, and Edsthetic supports those with all requested technical information

6.5 Remediate

• Apply code fixes, configuration changes, or process changes that prevent recurrence
• Retest the affected systems; run ZAP DAST over the staging environment before reopening production
• Document the remediation in the incident report

6.6 Post-incident review (within 14 days of resolution for P1/P2)

• Written post-incident review including timeline, root cause, impact, remediation, and lessons learned
• Review shared with affected schools on request
• Actions tracked to completion in the Edsthetic engineering backlog

7. Communications

During an active incident, Edsthetic communicates with schools through:

• Direct email to registered coordinators
• The Edsthetic status page (when available)
• Emergency SMS to the registered coordinator phone number for P1 events

Edsthetic does not disclose incident details on social media, through teacher/student-facing channels, or in public forums until schools have been individually notified and a coordinated public statement is agreed.

8. Backup and recovery

Recovery depends on the nature of the incident:

• Data loss: Supabase automated daily backups provide 7 days of point-in-time recovery. Recovery is to a separate environment first for forensic validation; only then is data restored to production
• Service outage: redeploy from the latest working commit; the product is entirely static HTML plus edge functions and can be restored within 30 minutes with no data loss
• Subprocessor outage: fallback depends on subprocessor; see subprocessor dependency map in internal engineering documentation

9. Records

Edsthetic maintains an incident register including:

• Every incident at severity P3 or higher
• Date detected, date resolved, severity, scope, root cause
• Notification timeline: schools notified, OAIC notified (if applicable)
• Remediation outcome

The register is retained for six years. Schools may request incident reports relating to their own data at any time within that window.

10. Testing

• Tabletop exercise: at least annually, the response team walks through a simulated P1 incident covering detection, containment, notification, and post-incident review
• Restore test: at least annually, Supabase point-in-time restore is tested to a non-production environment to confirm backup integrity
• ZAP DAST: the staging environment is scanned by OWASP ZAP at least quarterly once the Edsthetic admin is out of its initial commercial launch phase

11. Contact

12. Review

This plan is reviewed annually by the Edsthetic co-founders. Material changes are communicated to schools by email at least 30 days before they take effect.

---

Related documents: Security & Privacy · Data Deletion Policy · Staff Security Training · Data Processing Agreement (PDF)