A school may approve an education platform believing it will receive only names and class assignments. Months later, the same system may also hold test scores, attendance records, teacher comments, voice recordings, device identifiers, activity logs, and every prompt a student entered into an AI feature.
That expansion is where many privacy problems begin.
Understanding how student data privacy works in EdTech requires more than a FERPA statement, a parental-consent checkbox, or a GDPR clause. Schools and providers need to know what the product collects, why it is needed, who can access it, how long it remains available, and whether access or deletion requests can be handled safely.
FERPA, COPPA, and GDPR address different relationships. A platform may satisfy one framework while creating problems under another. Other national and state rules may add further duties.
Three Laws With Different Starting Points
FERPA governs education records maintained by covered US educational agencies and institutions. COPPA regulates certain online services that collect personal information from children under 13. GDPR applies more broadly to personal-data processing by controllers and processors within its territorial scope.
The starting question changes with the framework:
- Under FERPA: May the school give a provider access to education-record information?
- Under COPPA: May the operator collect this information online from a child, and who must authorize it?
- Under GDPR: Who determines the purpose of processing, and what lawful ground supports it?
One platform can raise all three questions, so the contract, product settings, and actual data practices all matter.
Student Data Goes Beyond Names and Grades
Education products may process names, school email addresses, student numbers, class assignments, test scores, attendance, and teacher feedback.
They may also generate IP addresses, device identifiers, login histories, pages viewed, search terms, crash reports, and approximate location.
Student-created material can be more sensitive. Essays, recordings, support messages, and AI prompts may reveal learning difficulties, family circumstances, or health information.
Removing a name does not necessarily make a record anonymous. A combination of school, class, age, device, activity history, and writing style may still identify the student. Under GDPR, pseudonymized or encrypted records remain personal data if they can be linked back to a person.
A vendor retaining “de-identified” information should explain what was removed, what remains linkable, and how re-identification is prevented.
FERPA: Schools Must Retain Control
FERPA applies to educational agencies and institutions that receive funds through programs administered by the US Department of Education. It covers public school districts and many colleges and universities. Private elementary and secondary schools are generally outside FERPA because they usually do not receive those federal funds directly.
Parents may inspect records, seek correction of inaccurate or misleading information, and exercise some control over disclosure. Those rights transfer at age 18 or when the student attends a postsecondary institution.
A covered school must provide access to requested education records within a reasonable time and no later than 45 days after receiving the request. State law may require a faster response.
When a Vendor Can Act as a School Official
FERPA’s school official exception may allow a provider to access education records without individual consent. The provider must perform a service the school would otherwise use employees to perform, meet the school’s criteria for a legitimate educational interest, and remain under the school’s direct control regarding the records.
It must use the information only for authorized purposes and avoid unauthorized redisclosure.
Direct control should be visible in practice. The school should be able to limit purposes and access, obtain records, require security, stop unrelated commercial use, and control end-of-contract handling.
A provider that claims broad rights to use identifiable student work for advertising, unrelated research, cross-customer profiling, or general AI training may be acting outside the educational role on which the school relied.
Vague “service improvement” language deserves scrutiny. Improving the classroom product is not the same as using student records to build an unrelated commercial system.
FERPA does not expressly require a written contract in every such case, but an agreement is usually the clearest way to establish control. It should cover purposes, access, subprocessors, security, incidents, retention, deletion, data return, and secondary uses.
Directory information is also narrower than it sounds. A school may designate limited categories, such as names or grade levels, only after providing notice and allowing opt-outs. That does not make all email addresses, profile fields, or app activity freely reusable.
COPPA: The Provider Has Direct Duties
COPPA applies to commercial websites and online services directed to children under 13 that collect, use, or disclose personal information. It also covers general-audience services that have actual knowledge they are collecting personal information from a child under 13.
A “users must be 13” clause is not conclusive. Regulators also consider the product’s design, language, audience, advertising, and actual users.
A child-directed service must also review third-party code. Analytics tools and software development kits may collect identifiers, and using another company does not remove the operator’s responsibility.
School Authorization Has Limits
A school may authorize collection on behalf of parents when the operator uses the information for the school’s benefit and for no unrelated commercial purpose.
The provider must explain its collection and disclosures. The school must be able to review the information, request deletion, and stop further use.
For example, an adaptive math platform may use a child’s answers to select the next problem. That is different from using the same history to build an advertising profile or train a general commercial model.
School authorization does not transfer the provider’s COPPA responsibilities to the teacher or school.
The Updated COPPA Rule Is Now in Force
The FTC’s amended COPPA Rule became effective on June 23, 2025. The general compliance date for most updated requirements was April 22, 2026.
Covered operators must maintain a written information-security program, assign responsibility, assess risks at least annually, implement and test safeguards, and review service providers.
Retention rules are stricter as well. A covered operator may keep a child’s personal information only for as long as reasonably necessary for the original purpose. It must maintain a written retention policy, and indefinite retention is prohibited.
The amended rule expressly covers certain voiceprints, faceprints, facial templates, gait patterns, and other recognizing biometric identifiers. Voice tutoring, facial authentication, and remote proctoring therefore need closer review.
Separate parental consent may also be needed for non-integral third-party disclosures.
GDPR: Consent Is Often the Wrong Starting Point
The GDPR applies to organizations established in the European Union when they process personal data as part of their activities. It may also apply to companies outside the EU when they offer goods or services to people in the EU or monitor their behavior there.
Consent is only one lawful ground. Others include contractual necessity, legal obligations, public-interest tasks, official authority, and legitimate interests where the required conditions are met.
Public schools may process some information under national law or a public-interest education task. Consent may be unsuitable when a student cannot realistically refuse a required system.
A compulsory checkbox does not become valid consent simply because the interface records a click.
Roles Must Match Reality
A controller determines why personal data is processed and makes essential decisions about how. A processor handles it on the controller’s behalf and under its instructions.
In a typical deployment, the school may be controller and the provider processor. Their contract must set out instructions and protections, including subprocessor controls.
Roles can change by activity. A provider may act as a processor while hosting assignments but as a controller if it independently uses the same information for advertising, unrelated research, cross-customer profiling, or general AI training.
Contract wording alone does not decide the issue. The actual decision-making does.
Children’s Consent and Individual Rights
When an online service is offered directly to a child and consent is the lawful ground, the age at which the child may consent varies among EU member states from 13 to 16. Below the applicable age, authorization from a person with parental responsibility is generally required.
This does not mean every European school needs parental GDPR consent for every learning platform or attendance record. Another lawful ground may apply.
The GDPR provides rights involving access, rectification, restriction, objection, and, where the conditions apply, erasure and data portability. Organizations must generally respond without undue delay and within one month.
The right to erasure is not absolute. Records may still be required by law, for a public-interest task, or for legal claims.
The practical test for a provider is whether it can find one student’s information across databases, files, analytics tools, support tickets, and backups without exposing classmates’ records. A deletion promise has little value if the product cannot perform it.
Privacy by Design and High-Risk Features
A privacy-conscious product should collect less, expose less, and require fewer perfect decisions from teachers and students.
Useful controls include private profiles, limited single sign-on fields, class-based access, separate support permissions, disabled advertising trackers, logged exports, and deletion schedules.
Production data should not be copied casually into development or demonstration systems. New integrations should be reviewed before they receive student information.
Some tools need deeper scrutiny. Under GDPR, a Data Protection Impact Assessment is required where processing is likely to create a high risk to people’s rights and freedoms. Schools and providers should consider one before using facial recognition, biometric authentication, remote proctoring, emotion detection, predictive discipline systems, persistent classroom recording, or AI trained on identifiable student submissions.
The review should go beyond cybersecurity. A system can be secure and still be unfair or overly intrusive. Emotion-recognition scores deserve particular skepticism because confidence does not establish accuracy.
A Practical Compliance Path
Legal review should follow the data, not begin and end with a privacy policy.
Start by mapping the full data flow, including integrations, analytics, support systems, exports, and testing environments.
Assign a specific purpose to every collection. “Analytics,” “research,” and “service improvement” are too broad. An event log used for security is not the same as one used for product development or AI training.
Make the contract match the product. It should cover authorized purposes, roles, subprocessors, security, incident reporting, access requests, hosting locations, retention, deletion, data return, and AI use.
Schools should not assume that a ban on “selling student data” prevents a vendor from using assignments, recordings, or prompts to train its own model.
Test deletion across databases, files, analytics, support tickets, logs, backups, and archives. Delayed backup deletion should be explained, and deleted records should not return to normal use.
Incident planning matters too. Under GDPR, a controller may need to notify the relevant supervisory authority within 72 hours after becoming aware of a breach likely to create a risk to individuals. A processor must notify the controller without undue delay. FERPA does not impose one universal federal deadline, although state laws, contracts, and other rules may apply.
Questions Schools Should Ask Vendors
A procurement team should request clear answers:
- What information do you collect, and which fields are optional?
- Do you use student data for advertising, profiling, research, AI training, or unrelated product development?
- Which subprocessors receive the information?
- Where are live records and backups stored?
- How quickly will you report a suspected incident?
- Can you export, correct, restrict, and delete one student’s information?
- What happens when a student leaves or the contract ends?
- Can privacy terms or subprocessors change without prior notice?
Security certifications may support the review, but they do not replace clear answers. An encrypted platform can still collect too much or use data inappropriately.
Final Thoughts
The best way to understand how student data privacy works in EdTech is to treat FERPA, COPPA, and GDPR as operating constraints, not marketing labels.
FERPA requires covered US schools to protect education records and maintain control when providers receive them. COPPA places direct obligations on covered operators collecting personal information online from children under 13. GDPR requires a lawful basis, accurate roles, enforceable rights, limited retention, suitable security, and privacy-aware design.
For schools, the first step is to map which tools receive identifiable student information and whether their contracts match their features.
For providers, the first step is: list every category of student data, every purpose, every recipient, and every deletion rule.
A responsible EdTech product should be able to explain where student information goes, why each use is necessary, and how the school can stop it. When those questions cannot be answered clearly, the problem is not the privacy notice. It is the service itself.
