Seven years after GDPR came into force, the majority of private K-12 schools in Romania and Bulgaria have a privacy policy on their website, a data protection agreement with their software providers, and a named Data Protection Officer. The majority also have teachers forwarding student medical information over WhatsApp, parents sharing class photos in groups that include people the school never vetted, and enrollment forms stored in Google Drive folders with access rights that nobody has reviewed since 2021.
The gap between documented compliance and operational compliance is where schools are actually exposed. This post covers the areas where we see the most substantive violations in the schools we work with, and what fixing them actually involves.
Understanding what GDPR actually requires from schools
Schools are data controllers under GDPR. They collect, store, and process personal data about children — a category of data subject that receives heightened protection under Article 8. The lawful basis for most school data processing is Article 6(1)(b): processing necessary for the performance of a contract, which in this context is the enrollment agreement. Medical and special educational needs data falls under Article 9 special category data and requires explicit consent.
The obligations that flow from this are not primarily about having a policy document. They are about being able to demonstrate that every piece of personal data the school holds was collected with a lawful basis, is used only for the purpose it was collected for, is accessible only to the staff members who have a legitimate need to see it, and can be erased or transferred when the data subject makes a valid request.
In practice, most school violations are not about the collection and storage of data. They are about the access and sharing of data once it is in the school's systems. The documentation says the school takes GDPR seriously. The day-to-day practice shows that access controls are rarely enforced and data is shared through channels that are not covered by any Data Processing Agreement.
The WhatsApp problem
WhatsApp is not GDPR-compliant for the sharing of student data. It does not provide the contractual data processing agreements that GDPR Article 28 requires from processors. When a teacher forwards a student's medical alert to a colleague via WhatsApp, that data now exists on WhatsApp's servers, accessible to Meta's infrastructure, without any contractual basis that gives the school control over how it is used or deleted.
This is not a theoretical risk. In 2023, a school in Hungary received a complaint from a parent after discovering that their child's allergy information had been shared in a teacher WhatsApp group that included a classroom assistant who had left the school six months earlier. The school had no mechanism to remove the data from the former employee's device because it existed in a personal WhatsApp conversation. The national data protection authority issued a formal warning and required the school to implement a messaging policy within 90 days.
The technical solution is straightforward: school communications that include student personal data must go through a platform with a DPA, role-based access controls, and audit logs. The hard part is changing a cultural habit. Teachers use WhatsApp because it is fast and familiar. The transition requires either providing them with a platform that is equally fast and more appropriate — which is what Kinderpedia's teacher-to-teacher messaging is designed to be — or accepting the compliance risk indefinitely.
Photo and video sharing: the consent gap
Class photos, sports day videos, and school event footage are among the most commonly mishandled data types in European private schools. Schools typically collect consent for photography during enrollment, but the scope of that consent is rarely specific enough to cover how photos are actually used in practice.
A consent form that says "we may use photos of students in school communications" does not cover: posting photos to a public Instagram account, sharing photos in a parent WhatsApp group where the school does not control membership, including student images in marketing materials that will be displayed in public spaces, or sharing class photos with parents before verifying that every child in the photo has consent on file.
Schools that use Kinderpedia's parent communication module can control exactly who receives each photo. A class album post goes only to the parents of students in that class. The photo never exists on a public platform. The permission record for every student in the photo is attached to the post. If a student does not have photography consent on file, the system flags the post before it is sent.
Schools that operate without this kind of controlled channel are effectively relying on teachers to manually check consent records before every photo post, which does not happen in practice. The photographs get shared because they are nice and parents appreciate them, and the compliance risk is invisible until it is not.
Access controls: who can see what
In a well-structured SIS, each staff member has access to the student records relevant to their role. A class teacher sees the records of their own students. A subject teacher sees the records of students in their classes. A learning support coordinator sees all IEP records. The school nurse sees all medical records. The headteacher sees everything. Administrative staff see enrollment and billing data but not grades or behavioral records unless they have a specific need.
In practice, most SIS implementations in European private schools have one or two user permission levels: administrative access and teacher access. Everyone with a teacher account can see every student's records, including medical histories, safeguarding flags, and family contact information that may be subject to court orders about which parent is permitted contact.
GDPR's data minimization principle requires that access to personal data be limited to what is necessary for the purpose of the processing. A physical education teacher does not need access to a student's SEND assessment report to deliver a PE lesson. A finance administrator does not need access to a student's attendance record to issue an invoice. The principle is clear. The implementation requires a platform with role-based access controls granular enough to enforce it.
Kinderpedia's permission model allows schools to configure access at the data-category level: who can see medical data, behavioral records, financial data, academic assessments, and personal family information can each be set independently. The audit log records who accessed what and when, which is the evidence base required under GDPR Article 5(2) accountability.
Data retention: the forgotten obligation
GDPR requires that personal data is not retained longer than necessary for the purpose for which it was collected. For schools, this means that student records should be deleted or anonymized after a defined retention period following the student's departure. The typical retention period for academic records is 5 years after the student leaves; for financial records, 7 years; for safeguarding records, 25 years or until the student's 25th birthday, whichever is later.
In our experience, fewer than 20% of private schools in Romania and Bulgaria have an active data retention schedule. Student records from students who left 10 years ago are sitting in databases, fully accessible to current staff, with no plan for deletion. This is not malicious — it is neglect born from the fact that data deletion is not visible the way data collection is. No one notices that you are retaining data you should have deleted. The regulator notices when they audit you.
Implementing a retention schedule requires three things: knowing what data you hold and when it was created, having a system that can selectively delete records by category and date, and assigning someone ownership of the deletion process. The last item is the most commonly neglected. Data deletion is not exciting. It does not have a natural owner. Assigning it to the DPA as part of an annual review cycle is the most practical approach for schools without a dedicated IT function.
The parental rights request problem
Under GDPR Articles 15-20, data subjects (or their parents, for children under 16) have the right to access their data, correct inaccurate data, request deletion in certain circumstances, and request a portable copy of their data. Schools receive these requests less frequently than commercial organizations, but they do receive them — typically from parents during contentious situations, such as enrollment disputes, behavioral incident appeals, or safeguarding investigations.
Responding to a Subject Access Request under GDPR requires the school to produce all personal data held about the subject within 30 days. Without a properly structured SIS, this task typically takes 3 to 5 days of staff time: searching email archives, compiling records from multiple systems, printing or scanning documents, redacting data about third parties (other students whose records appear in the same documents), and assembling everything into a coherent response package.
With a well-configured SIS, the same task takes 30 to 60 minutes. The student record contains the structured data; the audit log contains the access history; the document attachments contain the uploaded files. The redaction of third-party data still requires human review, but the compilation step is replaced by a data export. The 30-day statutory clock is the same either way. The difference is whether the school spends 30 minutes or 30 hours on the response.
What the most common GDPR audit finding is in European private schools
Based on conversations with our customers who have been through national DPA audits in Romania, Bulgaria, and Hungary over the past three years, the most common finding is not a specific technical violation. It is the absence of a current, accurate Record of Processing Activities (ROPA) under GDPR Article 30.
A ROPA documents every category of personal data the school processes, the lawful basis for processing, who has access, how long it is retained, and which third-party processors have access to it. Most schools created a ROPA in 2018 when GDPR came into force and have not updated it since. If the school switched from one SIS to another, added a new third-party enrichment program, changed their cloud storage provider, or started using a new communication platform, the ROPA is now inaccurate.
An inaccurate ROPA does not by itself constitute a GDPR violation. It is evidence of inadequate documentation, which auditors treat as an indicator that the underlying processing practices are also poorly documented. Schools that walk into an audit with a current, accurate ROPA — even if it reveals some areas that need improvement — are treated meaningfully differently from schools that produce a six-year-old document. The attitude toward compliance matters as much as the specific violations.
Practical next steps for school administrators
If your school is concerned about its GDPR posture, the most useful place to start is not the policy layer. It is the operational layer: where is personal data actually flowing in your school, through which tools, shared with which people, and retained for how long. A one-day data mapping exercise conducted by a senior administrator with input from class teachers, the finance office, and the IT contact will surface more actionable findings than re-reading your privacy policy.
The second step is access review: who in your school has access to what data, and is that access still appropriate? This takes two hours and produces a list of changes. Those changes can be implemented in Kinderpedia's permission settings in an afternoon. The result is a school that is materially more compliant than before and has documented evidence of the review — which is exactly what a DPA audit looks for.