Squono · School supplier pack
DPIA template for schools (pre-filled)
Version 2026-09-30 v1 · Last updated 30 September 2026
Wilgenry Software Limited (trading as Squono), a company registered in England and Wales, company number 17392061, registered office 42a Church Street, Hatfield, England, AL9 5AW. Email hello@squono.com.
How to use this template
The school is the controller, so the DPIA is the school's. Squono has filled in everything it can describe about its own service. The school should check each section against how it will actually use Squono, change anything that differs, choose its lawful bases, and complete the sign-off rows at the end.
The structure follows the ICO's DPIA template: need, description of processing, consultation, necessity and proportionality, risks, measures, and sign-off. Schools in Ireland can use it alongside the DPIA template in the Data Protection Commission's toolkit for schools.
Note: The rows marked "To be completed by the school" are the school's own decisions and sign-off. Squono can't fill them in.
1. Why a DPIA is needed
The school is adopting a new online service that processes pupils' personal data, including names, teams, attendance, consent slip answers and photos, and parents' contact details. The Department for Education and the ICO expect a DPIA before a school adopts new technology that processes children's data.
2. Description of the processing
Nature
Squono is a team app for sport. In Schools mode, school staff use it to run school sport teams, and parents and carers use it to see fixtures, answer availability and consent slips, and receive updates. Pupils do not have accounts.
How data flows
- The school exports a pupil and parent list from its MIS (for example SIMS, Arbor or Bromcom) as a CSV file. A school administrator uploads it to Squono. Nothing is sent to parents until the school presses "Invite parents".
- Staff and parents use Squono in a web browser or the Squono app. Everything they send goes over HTTPS to Squono's servers on AWS Lightsail in London (eu-west-2): the app, the background worker and the PostgreSQL database.
- Photos and documents are stored in S3-compatible object storage in London (eu-west-2).
- Emails (invitations, reminders, notices and the lesson-leave list notification) go from Squono to Amazon SES in London (eu-west-2) and then to the recipient's email provider. Email subjects never contain pupils' names, team names or scores.
- Push notifications go through Google Firebase Cloud Messaging and Apple Push Notification service, only if a parent or staff member installs the app and allows notifications.
- Schools mode uses no video hosting (no Mux), no payments (no Stripe), and no analytics or advertising services.
Scope
| Item | Detail |
|---|---|
| People | Pupils in the school's teams; their parents and carers; school staff and visiting coaches. |
| Data | As listed in section 4 of the DPA (squono.com/schools/trust/dpa). No dates of birth; no medical details by default; no special category data by default. |
| Retention | As in the retention schedule (squono.com/schools/trust/retention), including automatic deletion of consent slip answers and emergency contacts. |
| Location | Hosting, storage and email in London. Push notifications and the mobile app's font download involve servers outside the UK. |
| Volume | To be completed by the school (approximate number of pupils, teams and parents). |
Context
- The data is about children, so it needs extra care. Parents expect the school to organise sport and to tell them about fixtures, transport and consent.
- Under KCSIE 2026 schools in England are mobile phone-free by default, which is one reason pupils have no accounts: parents and staff are the users.
- Parents may already use Squono for their children's clubs outside school. Their account is theirs; the school's data about their child stays under the school's DPA.
- There are no adverts, no data sales and no use of school data for Squono's own purposes.
Purposes
Organising school sport: fixtures, availability, team selection, consent slips, transport, lesson-leave lists, registers, results, awards, house competitions and sports days, photos, documents, and communication between staff and parents.
3. Consultation
| Who | Why | Done |
|---|---|---|
| Data protection officer | Advice on this DPIA and the DPA. | To be completed by the school |
| Designated safeguarding lead | Photos, communications, who can see whom, and pupils with safeguarding restrictions. | To be completed by the school |
| IT or network manager | Cyber security, two-factor authentication, data location and backups. | To be completed by the school |
| Head of PE or director of sport | How fixtures, slips and transport actually work in the school. | To be completed by the school |
| Parents | Told through the school's privacy notice (a template is in this pack). | To be completed by the school |
| Squono (processor) | This pre-filled template and the supplier pack. Questions to hello@squono.com. | Provided by Squono |
4. Necessity and proportionality
Lawful basis – the school's decision
The lawful basis is for the school to decide. The options schools commonly use are:
| Purpose | Lawful basis the school may choose | Notes |
|---|---|---|
| Organising school sport (teams, fixtures, availability, registers, transport, lesson-leave lists) | Public task (Article 6(1)(e)) for state schools. | Independent schools are not public authorities, so they may need to rely on legitimate interests or contract instead. |
| Photos | Consent, or legitimate interests with a clear opt-out, following the school's photo policy. | Squono uses the school's own consent records (imported from the MIS). Different uses (website, social media, press) may need separate consent. |
| Consent slips for away fixtures and trips | Consent, where the school's visits policy requires written consent; otherwise public task, with parents told and able to withdraw their child. | Photo consent is never bundled into a trip slip. |
| Publishing results | Public task or legitimate interests. | Public results never name pupils. |
| Emergency contact on a slip | The school's decision. | Deleted 7 days after the activity (30 days after the slip closes if it has no activity date). |
Data minimisation
- No pupil accounts, logins or email addresses.
- No dates of birth: the import keeps the year group only.
- No medical details by default: slips only ask whether anything has changed, yes or no.
- Lesson-leave lists contain name, year, form, times and staff only – never medical, SEND or consent-reason information.
- Results shown to the whole school community use first name and initial; public results and the website snippet use no names at all.
Accuracy, retention, rights and processors
- Accuracy: the school's MIS stays the source; the school re-imports to update. Photo consent older than 13 months is treated as "no".
- Retention: automatic deletion as set out in the retention schedule (squono.com/schools/trust/retention).
- Rights: Squono helps within 5 working days (DPA section 12, squono.com/schools/trust/dpa).
- Processor and sub-processors: Article 28 DPA; published sub-processor list (squono.com/schools/trust/sub-processors).
5. Risks and how they are reduced
Likelihood: remote, possible or probable. Severity: minimal, significant or severe. The ratings below are Squono's suggestion; the school should adjust them for its own circumstances.
| Risk | Likelihood | Severity | Measures in Squono |
|---|---|---|---|
| Information goes to the wrong person (a parent linked to the wrong pupil, or an invitation to the wrong email address) | Possible | Significant | Nothing is sent until the school presses "Invite parents". Parents see only their own children. Staff can unlink a parent. Safeguarding restrictions block every way of linking a restricted adult to a child. Email subjects are generic. |
| Results or pupils' names shared too widely | Possible | Significant | Results publishing levels (team families, school community, public). Primary results are private to team families by default, with ESFA trophy events handled separately. No pupil names in public. Pupils with a safeguarding restriction are never named outside staff and their own family. |
| Photo misuse, including location data in photos | Possible | Significant | Photos only after a consent import or the school's confirmation. "Do not photograph" badges. Unknown or expired consent counts as no. Location (EXIF) data is removed before upload in the web and mobile apps, and the server checks JPEG, PNG and WebP uploads for leftover GPS data. No face recognition. |
| A staff account is taken over | Possible | Severe | Two-factor authentication is mandatory for every school staff account before any school data can be seen. Passwords hashed with scrypt. Rate limits on sign-in and codes. Audit log. |
| A parent account is taken over | Possible | Significant | A parent sees only their own children and their teams. Email verification. Optional two-factor authentication. Rate limits. |
| Breach at Squono or a sub-processor | Remote | Severe | Security measures in the security overview (squono.com/schools/trust/security). Breach notice to the school within 24 hours as a target and 48 hours at most. Time-limited, school-approved support access. |
| Transfers outside the UK | Possible | Minimal | Hosting, storage and email in London. Push notifications only if a parent turns them on. No video hosting and no payment provider in Schools mode. |
| Data kept longer than needed | Possible | Significant | Automatic deletion of slip answers, emergency contacts, notifications and email copies. Leavers removed at the start of the next academic year. Deletion within 30 days at exit. |
| Confusion over who is responsible for a parent's account | Possible | Minimal | The DPA states the controller split openly and the parent privacy notice template explains it. No marketing to parents using school data. Squono Pro is not available to school teams. |
| Unsupervised contact between adults and pupils | Remote | Severe | Pupils have no accounts. Chat is off by default in Schools mode. No direct messages to pupils. |
6. Residual risk
With the measures above, Squono's view is that the remaining risk is low. The school should record its own view below. Points the school may want to note:
- Squono is not yet Cyber Essentials certified and has not yet had a penetration test.
- Audit logs are kept while the school uses Squono; there is no automatic deletion of them yet.
- Squono does not yet add its own encryption to the database server's disk or to the on-server backup files; encrypted off-site backups are planned.
- The mobile app downloads its fonts from Google, which sends the device's IP address to Google.
| Item | Decision |
|---|---|
| Residual risk rating | To be completed by the school |
| Measures the school will add (for example staff guidance) | To be completed by the school |
7. Sign-off
| Item | Name, role and date | Notes |
|---|---|---|
| Measures approved by | To be completed by the school | Integrate actions into the school's plan, with dates and owners. |
| Residual risks approved by | To be completed by the school | If a high risk remains, consult the regulator before going ahead. |
| DPO advice provided by | To be completed by the school | The DPO should advise on compliance and whether processing can proceed. |
| Summary of DPO advice | To be completed by the school | |
| DPO advice accepted or overruled by | To be completed by the school | If overruled, give reasons. |
| Designated safeguarding lead consulted | To be completed by the school | |
| Headteacher (or trust, council or board) approval | To be completed by the school | |
| This DPIA will be kept under review by | To be completed by the school | Review at least once a year and whenever the processing changes. |
| Next review date | To be completed by the school |