Data-processing terms

This page summarises, in plain language, the terms that apply between a school and SchoolTrendz when the school processes personal data (including children's data) using SchoolTrendz. A signed, fuller version of this addendum will be made available to schools directly; this page is a public, readable summary of it.

1. Purpose of this addendum

A school using SchoolTrendz decides what personal data to put into the platform and why — for example, student records, attendance, exam results and fee invoices. This addendum sets out how we handle that data on the school's behalf, alongside our terms of service and privacy policy.

2. Roles and definitions

• The school is the data fiduciary (what other laws call the data controller) for the personal data it enters into SchoolTrendz. It decides what to collect, why, and who within the school may see it.
• SchoolTrendz (SchoolTrendz) is the data processor: we process that data only to provide the platform, on the school's documented instructions (principally, the school's own configuration of roles, modules and settings, plus these terms).

3. Processing only on your instructions

We process a school's data only to run the SchoolTrendz platform as the school has configured it, and for purposes the school has agreed to (such as the AI assistant, once the assistant is switched on). We do not use a school's data for our own marketing, nor sell it, nor share it with anyone outside the sub-processors listed in section 6, without the school's agreement or a legal requirement to do so.

4. Confidentiality

Our team members who can access school data in the course of their work are bound by confidentiality obligations, and access to production data is limited to what is needed to operate, support and improve the platform — most day-to-day support does not require looking at a school's actual records at all.

5. Security measures

We apply the technical and organisational measures described on our security page, including:

• Role-based permissions enforced by the server, with each school's data kept apart from every other school's
• Strong password rules, account lock-out after repeated failures, and optional or role-mandated two-step sign-in
• Short-lived access tokens and an HttpOnly, Secure, SameSite=Strict refresh cookie
• In our cloud design: encrypted file storage and a managed database with automatic backups (and point-in-time recovery)
• In our cloud design: a web application firewall with sign-in rate limits, and secrets kept in a secrets manager rather than in code
• An audit log of changes and a 30-day recycle bin for undoing deletions

These measures are reviewed as the product develops; they are not, and should not be read as, a certification such as ISO 27001 or SOC 2.

6. Sub-processors

We use a small number of other providers ("sub-processors") to help run SchoolTrendz. We choose them carefully and hold them to confidentiality and security obligations.

We will update this table as sub-processors are confirmed, and will let schools know before adding a new one wherever we reasonably can.

7. Data breach notification

If we become aware of a security incident that affects a school's personal data, we will notify the affected school To be confirmed: the exact notification timeline we commit to, e.g. "without undue delay" , with what we know at the time, what we are doing about it, and what the school may need to do.

8. Helping with requests from individuals

Because the school holds the relationship with its parents, students and staff, requests to see, correct or delete personal data are normally best directed to the school first. Where a school needs our help to fulfil such a request — for example, exporting or deleting specific records — we will provide reasonable assistance through the platform's own tools (export, edit and delete functions) or directly, on request.

9. Deletion or return of data

When a school's agreement with us ends, the school can export its data as CSV, or ask us for a fuller export. We will then delete the school's remaining data from our production systems within a reasonable period, other than data we are required to keep for longer by law (for example, certain financial records), and subject to data that has already passed through the 30-day recycle bin and backup cycles winding down naturally.

10. Audit log

Every add, edit and delete is recorded in an audit log, noting whether it came from a screen or the system; every AI assistant lookup is recorded there too. A school's administrators can search and export this log, which can help demonstrate what happened to a given record and when.

11. Governing law and precedence

This addendum is governed by the same law as our terms of service (see that page's governing-law section). If anything here conflicts with a signed agreement between a school and us, the signed agreement takes precedence.

12. Contact us

For questions about this addendum, please use our contact page.