"The cloud" is not an answer.
A region and a law is.
Where data physically sits matters because it determines which law reaches it and what happens when it moves. For a school in the EU or EEA holding data about children, data held in the EU under GDPR is the simplest position: no transfer question arises, the supervisory authority is local, and families asking where their children's records live get a short answer. Data held elsewhere is not automatically wrong — there are lawful mechanisms for international transfers, and the detail of those mechanisms has changed more than once in recent years — but it is a question you then own, and a small school without legal support is usually better off not owning it.
Ask for the region in writing and ask a second question with it: does the data stay there, or is it replicated or backed up elsewhere? Backups are the part vendors most often overlook in their own answer, and a backup in another jurisdiction is still a transfer. A vendor that answers both without hesitation has thought about this before you asked; one that has to check has probably never been asked by a school.
Ask to read it
before you sign, not after.
When you use a platform to hold student data, you are the controller and the vendor is your processor, and the relationship is supposed to be governed by a written agreement. Most vendors have one; many keep it a click away from where you would look. It should say what the vendor may do with the data (only what you instruct), that staff are bound by confidentiality, what security measures are in place, whether and which sub-processors are used, that the vendor helps you meet requests from individuals, what happens to the data at the end of the contract, and that you can audit or receive evidence of compliance.
Read it during evaluation rather than after signature, and read the sub-processor list in particular, because that is where the surprises live — an analytics provider in another jurisdiction, a support tool that can see customer records, a backup service you had not considered. None of those is necessarily a problem; all of them are things you as controller should know before a parent asks who else sees their child's data.
Send them by email,
so the answers exist afterwards.
These six settle most of what a school needs to know, and asking them in writing serves two purposes: you get an answer you can keep, and you learn how a vendor behaves when asked something precise. The middle column is what a good answer sounds like from anyone; the right-hand column is ours.
Two more worth adding for any vendor: how would a breach affecting our data be reported to us, and how quickly; and if we leave, can we export every student, enrolment, payment and attendance record, in what format, and is that in the contract? The second is in the buyer's guide too, because it is as much a commercial question as a compliance one.
Who can press the button
is the question most vendors skip.
SprintUp holds school data in the EU under GDPR; the company is Intellect Education Limited, registered in Ireland. An export produces everything held about one account as a single readable document. An erasure removes everything that identifies the person while keeping the account's place in the school's records, so that grades, attendance and class history stay internally consistent and the account can never be signed into again; notifications and preferences are removed outright. Administrative actions on accounts — including export and erasure — are written to an audit log with the actor, the target and the time. A student or parent can also delete their own account, which runs the same erasure path, so there is one definition of what erased means rather than two.
Now the limitation, because it is exactly the sort of thing this article tells you to ask about. The export and erasure operations are run by SprintUp rather than by your school administrator. Your administrators can see and manage their own students and can delete an account in a way that remains restorable; the formal export and the irreversible erasure are operator functions today, so a school fulfilling a request raises it with us and we execute it. We would rather write that here than have a DPO discover it during an actual request with a clock running. If it matters to your evaluation — and for a school that expects frequent requests it should — ask us, and ask every other vendor, the same question: who can run it, and what response time do you commit to?
The platform is rarely
the only vendor.
A school's data protection position is not set by its main platform alone. Payments run through a processor — for SprintUp that is Stripe, on the school's own connected account, which is its own controller relationship for payment data and worth understanding separately. Live video, email, messaging and any analytics tool each hold or transmit something. The inventory in the first article is where these surface; this is where you decide what to do about them.
The reduction that helps most is consolidation. Every system removed is one fewer processor to assess, one fewer agreement to hold, one fewer place to search during a request, and one fewer thing to remember when a teacher leaves. It is the least glamorous argument for an all-in-one platform and probably the strongest one for a school without a compliance function.
The vendor
checklist.
As with the rest of this cluster, none of it is legal advice; it is the set of questions that lets someone qualified give you an answer quickly.