Privacy Information & UK GDPR Processor Statement

1. What this document covers

This document explains how TutorPulse processes personal data when a school uses the classroom dashboard. It supports, but does not replace, the school’s own pupil, parent and staff privacy notices or the Article 28 data processing agreement between the school and TutorPulse.

The school decides why pupil data is used, which pupils and staff are included, how long records are needed and how data-subject rights are handled. TutorPulse uses the data only to provide, secure, support and maintain the service, unless the law requires otherwise.

2. Lawful basis and sensitive information

The controller must document a lawful basis for each processing purpose. Depending on the school and purpose, this may include public task under Article 6(1)(e), legal obligation under Article 6(1)(c), or another basis selected by the controller. TutorPulse does not choose that basis on the school’s behalf.

Mood selections are not used to make medical diagnoses. However, identifiable wellbeing information may reveal or become information concerning health or safeguarding. Schools should treat it as highly sensitive and decide whether an Article 9 condition and a Data Protection Act 2018 Schedule 1 condition are required. The school’s DPO should record this decision in its DPIA.

3. Personal data processed

• Accounts: staff name, school email, Firebase user identifier, role, school identifier, login/security metadata and subscription settings. Passwords are handled by Firebase Authentication; TutorPulse does not store readable passwords.
• Rosters and attendance: pupil name or school-chosen alias, stable internal pupil identifier, form, present/absent status and house-point totals.
• Wellbeing check-ins: pupil identifier, selected state (Bright, Calm, Okay, Tired, Worried or Need a chat), time and date, suggested pattern signals and staff acknowledgement status.
• Classroom configuration: schedules, display preferences, app availability, class-pet settings and similar teacher-entered configuration.
• Operational data: app-use counts, synchronisation state, support communications, security events and technical logs needed to operate and protect the service.
• Device storage: selected classroom state and pending offline changes may be held in LocalStorage, browser cache or IndexedDB on the school-controlled device until synchronised or cleared.

TutorPulse is not intended to hold addresses, dates of birth, medical records, detailed safeguarding narratives, contact details for parents, or free-form pastoral case notes. Schools should not enter those details.

4. Purposes and data flow

Data is used to authenticate staff, provide form registers, record classroom attendance, operate classroom features, present authorised staff with wellbeing check-ins, maintain open conversation requests, synchronise offline changes, support users and protect the service.

School-owned data is stored under tenant paths such as /schools/{schoolId}/forms/{formId}, with mood records and follow-up states in form subcollections. During the documented schema migration, compatibility copies of some form configuration may also exist under the owning staff account. These copies remain subject to the same authentication and deletion process and should be removed after migration verification.

Generative AI: pupil names, attendance and wellbeing records are not sent to Gemini. Gemini is used by server-side functions to create general educational question pools and, when a signed-in teacher requests it, discussion prompts based on a news headline and description.

5. Access, isolation and security

• Firebase Authentication verifies users and issues signed identity tokens.
• Firestore Security Rules restrict browser access using the authenticated user’s school, role and assigned forms. Server functions separately verify privileged custom claims.
• School data is separated by tenant and form. Assigned teachers see their forms; school administrators and authorised super administrators have broader access needed for administration.
• Cloud Firestore applies provider-managed encryption at rest, and browser/service connections use HTTPS/TLS encryption in transit. Encryption does not remove the need for strong accounts, device controls and least-privilege access.
• Offline queues use unique mutation identifiers to reduce accidental replay. School devices remain the school’s responsibility and should use managed accounts, screen locks, supported browsers and appropriate clearing/sign-out procedures.

No service can promise that a breach is impossible. Suspected incidents must be reported promptly to [INSERT SECURITY CONTACT] so TutorPulse can investigate, contain the issue and support the controller’s breach assessment.

6. Hosting location and international transfers

TutorPulse uses Google Firebase/Cloud Firestore and Netlify hosting/serverless functions. The exact production Firestore database location is fixed when the database is created but is not recorded in this public source repository. The applicable order form or data processing agreement must identify the verified production region before pupil data is onboarded.

Do not describe the service as “UK-only hosted” unless the production database and relevant processing services have been verified in writing. A Firestore database in europe-west2 is London; eur3 is an EU multi-region. Network routing, support access, content delivery and subprocessors may still involve processing outside the UK.

Where personal data is transferred outside the UK, TutorPulse and its providers must use an applicable adequacy regulation or appropriate safeguards, such as the UK International Data Transfer Addendum, and assess supplementary measures where required.

7. Providers and subprocessors

• Google Firebase / Google Cloud: authentication, database and associated cloud security services.
• Netlify: website delivery and serverless function execution.
• Google Gemini API: general educational content and teacher-requested news discussion prompts; no pupil roster, attendance or mood data is intentionally submitted.
• Content services and CDNs: browser requests may be made to approved providers for icons, fonts, audio, book/news data or other classroom content. Schools should review these services within their filtering and procurement process.

The contractual subprocessor schedule, locations, transfer safeguards and change-notification process should be attached to the school’s data processing agreement. Provider lists may change; material changes affecting school data should be notified in accordance with that agreement.

8. Retention and deletion

• Wellbeing check-ins: retained for the school-selected 30 or 90 days, then removed by the nightly retention process.
• Follow-up states: retained separately while required for the school’s workflow and removed on controller instruction or account deletion. They are not a substitute safeguarding record.
• Rosters, attendance and configuration: retained while the school account is active and then deleted or returned in accordance with the contract and documented controller instructions.
• Local browser data: remains on the school-controlled device until synchronised, removed by the application, cleared by the school or expired by the browser.
• Backups and provider logs: may remain for limited provider-controlled periods stated in the applicable contract or subprocessor terms.

Schools should align these periods with their retention schedule. Data must not be retained merely because storage is available.

9. Children’s rights and controller requests

Pupils may have rights of access, rectification, erasure, restriction, objection and complaint, depending on the circumstances and lawful basis. A child may exercise their own rights when competent to do so; a person with parental responsibility may act where legally appropriate.

Requests should normally be made to the school as controller. TutorPulse will assist the school with searches, correction, export, restriction or deletion where required by the data processing agreement. Freedom of Information requests and data-protection requests are different legal processes and should not be treated as interchangeable.

Complaints should first be raised through the school’s published process or TutorPulse privacy contact as appropriate. Individuals may also complain to the Information Commissioner’s Office.

10. Wellbeing and safeguarding boundaries

The Wellbeing Signals feature supports staff awareness. It does not diagnose, score, rank or make a solely automated decision about a pupil. “Need a chat” remains visible to authorised staff until acknowledged; repeated worry or tiredness produces a suggested check-in based on recorded school days.

Staff must apply professional judgement and follow the school’s safeguarding policy. TutorPulse is not an emergency reporting channel, and the school must maintain its established DSL and safeguarding-record system.

11. Review and changes

This document should be reviewed when the service, providers, database location, retention settings, legal requirements or school use changes. Material changes should be communicated to subscribing controllers before they take effect where required.