Home›Blog›School operations›C7 · Data protection and GDPR
P12 · School operations›Cluster 7 of 9

C7 · Data protection and GDPR
You are the controller. The platform is only a processor.

A school holds more sensitive data than most businesses its size, most of it about children, and buying software does not move that responsibility anywhere. What you hold, what a vendor can genuinely do for you, and what happens when a family exercises a right.

3
Articles
~28 min
Total reading
Schools
Audience

Before anything else, the disclaimer that this cluster needs and that you should expect from anyone writing about this: none of it is legal advice. Data protection law differs in its details between countries even inside the EU, schools inside compulsory education often carry additional duties, and the guidance a supervisory authority gives to a state school is not always what applies to a private language academy. What follows is the operational shape of the obligation, written for a small school without a legal department, so that you know which questions to take to someone who can answer them properly.

With that said, the core fact is simple and often misunderstood: the school is the data controller. You decide what data is collected about students and families, why, and how long it is kept. A software vendor that stores it on your behalf is a processor acting on your instructions. Buying good software makes the obligation easier to meet and does not move it. Any vendor implying otherwise — "we handle GDPR for you" — is describing something that is not possible.

What a school holds

More than most businesses its size,
and most of it about children.

A typical small school holds names, dates of birth and addresses of children; contact details, and sometimes financial details, of parents; attendance records; assessment results and teacher comments; medical or dietary notes; sometimes safeguarding records; payment history; and, if it teaches online, recordings or connection logs of classes children appeared in. Several of those categories are sensitive in the specific legal sense, and nearly all of it relates to minors, who are given particular protection.

Almost no small school has this written down, and writing it down is the single most useful hour the cluster will ask you for. You cannot decide retention periods, answer an access request, or brief a vendor without knowing what you hold and where it lives — and "where" almost always includes places the school has forgotten: a teacher's personal spreadsheet, a WhatsApp group with parents, an old enrolment form in a shared inbox. The first article is that inventory, with the retention question for each category.

The obligations that actually bite

Five things a small school
is realistically judged on.

A lawful basis, and a clear one. Why are you allowed to hold this? For most school records it is the contract with the family or the school's legitimate interests; for marketing it is usually consent, which must be freely given and withdrawable. The common error is treating consent as the basis for everything, which creates the awkward position that a parent could withdraw consent for you to hold attendance records you are obliged to keep.

A privacy notice families can actually read. What you collect, why, who else sees it, how long you keep it, and how to exercise rights — in the language families speak, given at enrolment rather than buried in terms. It is also the cheapest trust-builder a school has.

Retention. Data is kept for as long as there is a reason and then deleted. "For ever, in case" is not a reason, and it is the default state of most schools.

The ability to answer a request. When a family asks what you hold, or asks for deletion, you have a limited window to respond — commonly a month under GDPR, with conditions. Knowing in advance how you would do it is the difference between a routine task and a panic.

A plan for a breach. Who is told, by whom, how quickly. Breaches at small schools are rarely dramatic: a register emailed to the wrong parent, a laptop left on a train. The obligation is about what you do next.

What a vendor can do

Make it possible.
Not make it theirs.

A platform cannot carry your obligation, but it decides whether meeting it is a morning's work or a fortnight of it. The things to look for are concrete: where the data is hosted and under which law; a written data processing agreement you can read before signing; the ability to get everything held about one person out, and to have it erased; control over who inside the school sees what; a record of administrative actions taken on accounts; and a clear answer about backups and how a breach would be reported to you.

A vendor should answer all six without checking. "We take security very seriously" is not an answer; "EU, under GDPR, here is the agreement, here is how export and erasure work and who can run them" is. The second article turns this into the questions to send by email, and includes SprintUp's own answers — including the limitation in the next section, which is the kind of thing most vendors leave for you to discover.

Where SprintUp stands, including the limit

Export and erasure exist.
Today you ask us to run them.

SprintUp holds school data in the EU under GDPR, and the company behind it, Intellect Education Limited, is registered in Ireland. The platform implements the two rights that matter most operationally: an export of everything held about one account as a single readable document, and an erasure that removes everything identifying the person while keeping the school's own records — grades, attendance, class history — internally consistent. Administrative actions on accounts, including exports and erasures, are recorded in an audit log with who did them and when. A user can also delete their own account, and that goes through the same erasure path, so there is one definition of what erased means.

The limitation, stated plainly: those export and erasure operations are currently run by SprintUp, not by the school administrator. A school admin can see and manage their own students, and can delete an account in a way that stays restorable — but the formal data export and the irreversible erasure sit with the platform operator, so a school fulfilling a subject access request raises it with us and we run it. Many SaaS products work this way and most do not say so on their marketing pages. It matters to you because your response clock keeps running while you wait, so if you are evaluating platforms, ask each one who can press the button and how quickly they commit to acting. The third article covers how to handle a request on that basis, and what erasure genuinely cannot remove — invoices, for instance, which are kept because accounting law requires it and erasure does not override that.

In this cluster

Three articles,
inventory, vendor, request.

Write down what you hold, ask your vendors the six questions, and know what you will do the day a family asks. Each article ends with a checklist, and none of them is a substitute for advice on your own jurisdiction.

Articles in this cluster
C71
A1Schools~9 min
What Student Data Your School Holds
The inventory almost no small school has written down, why it matters, and how long each kind should be kept.
C72
A2Schools~9 min
Data Residency and Vendor Questions
Where the data lives, what a processing agreement has to say, and the six questions a vendor should answer without checking.
C73
A3Schools~9 min
GDPR Rights Requests in a School
What happens when a family asks for their data or its deletion — including what erasure can and cannot remove.
← C6 · Reporting and analytics
Next clusterC8 · Multi-site and scaling →