Safeguarding statement
For designated safeguarding leads, heads of department and IT · last updated 17 September 2026
BugBot is a set of Python lessons, a robot simulator and class tools used in school computing lessons by students aged 11 and up. This page says, in plain terms, how it is built so that a student cannot be contacted, exposed to anyone else's content, or identified by anyone outside their own class. The detailed data handling is in the privacy notice, the page for students and parents, and the pre-filled DPIA.
The short version
- No contact between students, ever. There is no chat, no messaging, no comments, no profiles and no friend lists. A student cannot send anything to another student, in their class or anywhere else.
- No content from strangers. Everything a student sees is written by BugBotLab or by their own teacher. Nothing on the site is posted by other users.
- No accounts for students. A student joins a class with a code the teacher reads out. No email address, no password, no date of birth, no photograph. The teacher chooses whether students use a nickname, a school student number or the school's own sign-in.
- The teacher is in control. The teacher opens and closes the class, sees everything every student writes and prints, can remove a student, and can switch off the printed output on the projector.
- No adults from outside the school. BugBotLab staff never contact students and never have a reason to. Support goes through the teacher.
What a student can and cannot do
| A student can | A student cannot |
|---|---|
| Write Python programs and run them on a simulated robot | Send a message to anyone |
| Print text from their program to their own screen | See another student's code, name, number or email |
| Hand work in to their own teacher | Upload images, files or links |
| Enter a competition room with a nickname and race their program against classmates | Talk to anyone in the room, or see anything but nicknames and results |
| Leave the class at any time from the lessons page | Join a class without the code the teacher gave out |
The two places a student's words can be seen by others, and how they are controlled
Everything else a student types stays between the student and their teacher. These two are the exceptions, and both are under the teacher's control.
- A nickname in a competition room. Everyone in the room sees it, and it may be on the projector. A word filter blocks the obvious words and the usual ways round them, and the lesson page tells students to pick a name their teacher will recognise. The filter is deliberately modest: what keeps a room safe is that the teacher holds the room code, starts each race and can remove any entry at once.
- Printed output on the projector. When a class races on the projector, what each program prints can be shown so students can see their program working. The same filter covers the words, and the teacher can switch the printed log off entirely for the room.
Who can see a student's work
- The student, their own work only.
- Their teacher, for classes that teacher made. On a School plan, a department admin the school has named can also see the school's classes.
- BugBotLab Ltd staff, only to keep the service working or when the school asks us to, and only with two-factor authentication on the account that can do it. We do not read student work as a matter of course and we never use it to train AI.
Nobody outside the school can see a student's work, and no student can see another's.
Identity, and what the school decides
The teacher picks one of three ways to run a class, and the school's own policy decides which is appropriate:
- Nickname. The student types a name. Nothing is checked. Suitable when the school prefers to hold no identifying data with us at all; a first name and initial is enough for the teacher to know whose work it is.
- Class list. The teacher enters names and school student numbers; a student signs in by typing their number while the teacher has sign-in open. Numbers are checked on our server and never shown to other students. Too many wrong numbers close sign-in for two minutes, and the teacher can see and undo every sign-in.
- School sign-in. Students use the school's own Google or Microsoft account. We receive the email address and nothing else, and only the right student can sign in as themselves.
On shared computers, students press Leave at the end so the next person is not signed in as them. Teachers can remove a student's record at any time.
Content
All lesson content is written by BugBotLab and checked against the exam specifications. Lessons cover programming, algorithms, computer systems, networks, cyber security and the law and ethics of technology at the level the GCSE and A level specifications require. There is no advertising anywhere on the site, and no link takes a student to a site with user-generated content. The word filter on nicknames and printed output covers offensive words and slurs, written plainly or disguised with numbers, punctuation or spacing.
If something goes wrong
- A student in distress, or a disclosure made in a program or a hand-in, is a matter for the school's own safeguarding procedure. The teacher can see the work and who wrote it.
- A teacher who sees an inappropriate nickname or output removes the entry in the room, and can close the room.
- To report a problem with the service itself, email info@bugbotlab.com. We reply within two working days, one on a paid plan, and we will tell the school within 48 hours of any data breach that affects it.
What we ask of the school
- Decide which of the three identity options fits your policy, and tell teachers.
- Keep the class code to the class. A code is six characters and only works while the class is open.
- Remind students to press Leave on shared computers.
- Tell us if a student's record needs deleting and the teacher is unavailable; we act on the school's instruction within 30 days, usually the same day.
Where this fits with your policies
This statement is written to answer the online-safety questions in Keeping Children Safe in Education and the checks a designated safeguarding lead or data protection officer runs before a new tool is used: contact, content, conduct and commerce. For data protection specifically, the school is the controller and BugBotLab Ltd the processor under the data processing agreement, which applies to every school including those using the free tools. The DPIA template is pre-filled for your DPO. Filtering and monitoring stay with the school: the IT page lists the hosts to allow, and nothing on BugBot bypasses the school's filter.
BugBotLab Ltd, registered in England and Wales, company number 16669242. Registered office: 103 Ouseley Road, Wraysbury, Staines-Upon-Thames, TW19 5JJ. Contact: info@bugbotlab.com.