Data protection impact assessment: BugBot
Template for schools · pre-filled by BugBotLab Ltd, 11 September 2026 · print this page or copy it into your own template. The parts in italics are for the school to complete.
1. The processing
Description. Students learn Python and robotics through the BugBot lessons in a web browser. A teacher makes a class in BugBot Teach and gives students a six-letter code. Students join with the code and a nickname; no account, email or real name is needed. As they work, their task results and the last program they ran are saved so the teacher can see who is stuck and who has finished, send a hint, set assignments and lock modules.
Nature. Collection, storage and display of learning progress; automated checking of programs by a simulator; no profiling, no automated decisions with legal or similar effect.
Scope. Nickname, a random identifier, class code, current lesson, task results and attempts, the last program run (up to 4000 characters), the last error message, timestamps. Teacher email and name. Number of students: ___. Year groups: ___.
Context. Data subjects are pupils aged roughly 14 to 19 and their teachers. Pupils have limited say over the processing; the school decides to use the tool. Processing is what pupils and parents would expect from a classroom learning tool.
Purpose. To teach programming and robotics and to let the teacher see progress and help students in the lesson. BugBotLab's purpose as processor is only to provide this service.
2. Consultation
Who was consulted (DPO, computing department, IT, pupils or parents where appropriate) and when: ___
BugBotLab Ltd was consulted through its published privacy notice, IT page and this template.
3. Necessity and proportionality
| Question | Answer |
|---|---|
| Lawful basis | Public task (Education Act 1996 / Academies Act 2010) or legitimate interests; school to confirm. Analytics cookies rely on consent and are optional; blocking them does not affect the lessons. |
| Is the processing necessary? | Progress data is what makes the teacher features work. Students who are not in a class keep progress in their own browser only; the school can choose that mode for any group. |
| Data minimisation | No real names, emails, dates of birth or photographs are collected from students. Nicknames are chosen by students under the teacher's guidance. The program stored is limited to the last run and 4000 characters. |
| Accuracy | Data is generated by the student's own activity. Teachers can delete a student record or a class. |
| Retention | Class data is deleted when the teacher deletes the class, or 12 months after the class was last used. Teacher accounts 24 months after last sign-in. Feedback 12 months. |
| Transparency | Privacy notice published at teach.bugbotlab.com/privacy.html; the school adds BugBot to its pupil privacy notice: ___ |
| Individual rights | Teachers can view and delete student data directly. Other requests via info@bugbotlab.com, 30-day response. |
| Processors | Google Cloud (Firestore in London; Firebase Authentication; Hosting), Google Analytics (optional), Google Workspace (email), MailerLite (front page waitlist only). Google's Cloud Data Processing Addendum applies. |
| International transfers | Class data stays in London. Firebase Authentication may process sign-in data in the United States under the UK Addendum to the EU Standard Contractual Clauses. |
4. Risks
| Risk | Likelihood | Severity | Overall |
|---|---|---|---|
| A student types personal information into a program or a nickname, which the teacher can then see | Possible | Minimal | Low |
| Someone who knows a class code joins it under a false nickname | Possible | Minimal (they see only their own record; the teacher sees an unknown name and can delete it) | Low |
| Unauthorised access to the database | Remote | Significant | Low |
| Teacher account compromised | Remote | Significant (exposes nicknames and progress of their classes) | Low |
| Data kept longer than needed | Possible | Minimal | Low |
| Analytics collecting more than expected | Remote | Minimal | Low |
5. Measures
| Risk | Measure | Effect | Residual |
|---|---|---|---|
| Personal information typed in | Teacher guidance on nicknames in Getting started; the lessons never ask for personal details; program size capped | Reduced | Low |
| Code sharing | Codes are six characters from a 30-character alphabet; the teacher sees every joiner in real time and can delete a record; a class can be archived so its code stops working | Reduced | Low |
| Unauthorised access | Firestore security rules: a student writes only their own record; a teacher reads only classes they made; feedback is write-only; HTTPS everywhere; BugBotLab admin access limited to named staff with two-factor authentication | Reduced | Low |
| Teacher account compromised | Recommend Google or Microsoft school sign-in so the school's own MFA and offboarding apply; password sign-in uses Firebase Authentication with rate limiting | Reduced | Low |
| Retention | Published retention periods; teacher-initiated deletion; scheduled deletion of inactive classes | Reduced | Low |
| Analytics | Consent bar before any analytics cookie; Google Analytics 4 with IP truncation; no advertising features; analytics not needed for the lessons | Reduced | Low |
6. Sign-off
| Item | Name and date | Notes |
|---|---|---|
| Measures approved by | ___ | |
| Residual risks approved by | ___ | No residual high risk identified, so ICO prior consultation is not required |
| DPO advice | ___ | |
| Review date | ___ | Recommended yearly, or when BugBotLab announces a change to student data processing |