A note before we start: we are a software vendor, not a law firm — this article organises the practice, it does not replace legal advice. For binding questions, talk to your data protection officer or your lawyer.

In short: a study-abroad language school processes data about minors and health information — the five points where data protection is decided in practice: a data processing agreement with every tool, special handling for health fields, controlled data sharing with host families, a deletion concept, and a 72-hour plan for data breaches.

Language schools regularly underestimate how sensitive their data actually is. A study-abroad school does not just process names and billing addresses: there is data about minors, whose bookings are signed by their parents. There is health information from enrolment forms — allergies, intolerances, medication — intended for the host family and legally part of the special categories of personal data. There are passport details for visa paperwork, payment data, and around all of it a chain of parties: agency, school, host family, insurer.

That chain is exactly what makes data protection in a language school different from an ordinary small business. Here are the five points where, in practice, it is decided whether the topic is under control or not.

1. The data processing agreement — with every tool that sees student data

As soon as an external service processes personal data on your behalf — your management software, your e-mail provider, your newsletter tool — Art. 28 GDPR requires a data processing agreement (DPA). That is not a formality: the DPA defines where the data lives, who the sub-processors are and what happens in the event of a breach.

The practical test is simple: list every tool that contains student data and check whether a DPA exists for it. A serious management software vendor gives you one on request — together with a written overview of the technical and organisational measures. If you do not get one, that is a warning sign no feature list can outweigh.

2. Health information is not an ordinary form field

“Does your child have any allergies?” is probably the most common question on junior-programme enrolment forms — and its answer falls under Art. 9 GDPR, the special categories of personal data. In practice that means: this information needs its own legal basis (usually explicit consent), it does not belong in free-text fields that everyone on the team can see, and it should be deleted once the stay is over.

A management system helps with two things here: role-based permissions, so the accommodation team sees what the host family needs to know while accounting does not — and structured fields instead of free text, so that when it is time to delete, you can actually find what needs deleting.

3. The host family is a data transfer — treat it as one

For a placement to work, the host family has to know a few things: name, age, arrival time, dietary habits, possibly health notes. That is a transfer of personal data to a third party — permissible insofar as it is necessary for performing the contract, but only insofar as necessary. The host family needs the allergy information; it does not need the invoice history.

What works in practice is the principle of the graded view: the host family receives a defined data sheet, not the whole record. If you solve this by forwarding e-mails from your inbox, you lose exactly that control.

4. Being able to delete is part of the job

The GDPR does not require you to keep data forever — quite the opposite. Booking and invoice data are subject to commercial and tax retention periods; the 2019 enrolment form with health information is not. A workable deletion concept answers three questions: which categories of data exist, how long does each of them have a legal basis, and how is deletion done — systematically or by hand?

The same rule applies here: in a landscape of spreadsheets with copies in mailboxes, systematic deletion is practically impossible. In a central system, it is a feature.

5. The emergency has a deadline: 72 hours

A data breach — the lost laptop, the misdirected document, the compromised login — must be reported to the supervisory authority, as a rule within 72 hours (Art. 33 GDPR). That deadline only holds if you know in advance who on the team is responsible, how to contain the incident and which authority in your country is competent. A one-pager with those three answers is not bureaucracy — it is the difference between an orderly incident and a chaotic one.

What this means for choosing software

When you select management software, data protection is not a separate chapter next to the features — it lives inside them: role-based permissions, structured fields, defined partner views, deletability, a DPA without a chase. We have built these questions into our selection checklist — and how Fidelo handles hosting, roles and data processing is published openly on our security page.