Otiya Data Breach and Incident Response Plan
Version 1.0 · 14 October 2026
This plan sets out what Helixus Ltd (Otiya) does if something goes wrong with personal data, such as data being lost, seen by the wrong people, changed or made unavailable. It forms Annex 5 of the Otiya Data Processing Agreement.
Who does what
| Role | Name | Responsibility |
|---|
| Incident lead | Olalekan Obisesan, Founder and CEO | Runs the response, decides on notifications and keeps the record |
|---|
| Technical response | Olalekan Obisesan, with Otiya's engineers | Contains the problem, investigates, fixes and checks |
|---|
| Safeguarding lead | Olalekan Obisesan | Takes the lead when children may be affected |
|---|
Report anything suspicious to hello@otiya.xyz with "Incident" in the subject. Inside the team, tell the incident lead straight away, at any time of day.
Our timelines
| When | What we do |
|---|
| Straight away | Contain it: lock accounts, revoke keys, switch off the affected feature |
|---|
| Within 24 hours | Assess what data, whose, how many people, and the likely harm |
|---|
| Within 48 hours of becoming aware | Tell each affected school (DPA clause 9) |
|---|
| Within 72 hours of becoming aware | Report to the ICO, where Otiya is the controller and the breach is likely to put people's rights at risk |
|---|
| Without undue delay | Tell affected individuals directly where the risk to them is high, or support the school to do so |
|---|
| Within 2 weeks of closing | Review what happened and what to change |
|---|
For school data, the school is the controller and decides whether to report to the ICO and tell families. We give the school everything it needs to do that in its own 72 hours.
Steps
- Contain. Stop the breach spreading: reset or suspend accounts, rotate API keys and service credentials, switch off the affected function in Netlify, or restrict Firestore access.
- Assess. Work out what happened, which data and whose, roughly how many people, whether children are involved, and how serious the harm could be.
- Notify schools. Email each affected school's main contact and DPO with what we know: what happened, data and people affected, likely consequences, what we've done and what we'll do next. Send updates as we learn more.
- Notify the ICO where required (for data Otiya controls), on the ICO's breach reporting service or helpline.
- Tell people affected when the risk to them is high, in plain words, with what they can do to protect themselves.
- Fix. Repair the cause, test the fix, and check no data is still exposed.
- Record. Log every incident, including near misses and ones we don't need to report: date, what happened, data involved, decisions and reasons, and who was told.
- Learn. Update this plan, the security measures or the product so it doesn't happen again.
Subprocessor incidents
If Firebase, Netlify, Google Gemini or Brevo tells us about an incident affecting Otiya data, we follow the same steps and timelines from the moment they tell us.
Practice
We run a short practice of this plan once a year, for example "a laptop with an Otiya admin sign-in is stolen", and update the plan with what we learn.
Trust and safety | Otiya for Schools | Privacy
