Privacy & Safety
Trust is the precondition for everything an educational institution does. Students and families who trust the institution share more, engage more, and benefit more. Institutions that earn and maintain trust with clear privacy practices, honest data handling, and genuine security reduce their legal and reputational risk. Institutions that treat compliance as paperwork and privacy as an afterthought discover the cost of that choice when something goes wrong.
This guide covers the foundational legal framework (FERPA and related laws), what student data rights actually mean in practice, how to implement data minimization and security, how to evaluate technology vendors for privacy, and what it looks like to build an institution that students and families can genuinely trust with their information.
FERPA: what it actually requires
FERPA, the Family Educational Rights and Privacy Act, protects education records at educational agencies and institutions that receive funds under programs administered by the US Department of Education. Check whether your institution falls within that scope. Other privacy duties can apply even where FERPA does not.
What FERPA covers. Education records directly relate to a student and are maintained by an educational agency or institution, or by someone acting for it. Grades and disciplinary records are common examples. Specific exclusions have conditions, as described in the Department of Education’s records guidance.
Examples of excluded records include:
- Private memory-aid notes kept in the maker’s sole possession, subject to the temporary-substitute exception
- Records created and maintained by a law-enforcement unit for a law-enforcement purpose
- Records used only for an employment relationship; records of employment that depends on student status remain education records
- Records created after attendance ends that are unrelated to the person’s attendance
The consent requirement. Disclosure of personally identifiable information from education records generally requires signed, dated consent from the parent or eligible student, unless a FERPA exception applies. Access within the institution must also have a permitted basis.
Examples of permitted disclosure without consent, when the relevant conditions are met:
- School officials with a legitimate educational interest. Access must be needed for their duties.
- Other schools. Disclosure may support enrollment or transfer.
- Authorized representatives. Certain audits or evaluations of education programs qualify.
- Financial aid. Information may be needed to determine eligibility or administer aid.
- Parents of tax-dependent students. This exception can apply after rights transfer to the student at age 18 or on attendance at a postsecondary institution. Verify dependency and the disclosure basis.
- Health or safety emergencies. The exception requires an articulable and significant threat.
Review the Department of Education’s FERPA exceptions summary before relying on an exception. Its parental-access guidance explains the tax-dependency route.
The disclosure log. FERPA generally requires a record of requests for access to, and disclosures of, personally identifiable information from education records. The record identifies the parties and their legitimate interests. Specified exceptions include disclosures to the parent or eligible student, school officials, parties with written consent and parties seeking directory information. Retain the record with the education records and make it available for permitted inspection. See the Department of Education’s disclosure-record guidance.
Rights parents and eligible students have. The right to inspect records (institution has 45 days to comply — you cannot destroy records after a request is filed, and a delayed response after a request is a violation). The right to request amendment of inaccurate records (you can agree and fix them, or disagree and hold a hearing — you cannot ignore the request). The right to consent before disclosure to parties not covered by an exception.
FERPA: the mistakes institutions actually make
Posting grades publicly. Avoid releasing identifiable grades without consent or another valid disclosure basis. A student ID can still identify a student. Check aggregate results for re-identification risk, especially in small groups. Honors and awards may qualify as directory information only when the institution has properly designated them and followed its notice and opt-out process. See the directory-information guidance.
Talking to the wrong parent. Verify who holds FERPA rights and whether a court order or other binding document limits access. Rights transfer to the student at age 18 or on attendance at a postsecondary institution. After transfer, parental access requires consent or a valid exception, such as verified tax dependency. Payment of tuition alone does not establish the disclosure basis.
Third-party tools without written agreements. Review the lawful disclosure basis and the vendor’s permitted uses before sending student information. A written agreement helps establish the control required under the school-official exception. FERPA does not universally require a contract for that exception, although other laws or procurement rules may require one. The studies and audit/evaluation exceptions have specific written-agreement requirements. See the Department of Education’s school-official guidance.
Treating directory information as freely shareable. Directory information (name, enrollment status, graduation year, etc.) can be disclosed without consent only if the institution has published a notice explaining what qualifies as directory information and giving students the opportunity to opt out. Many institutions skip the notice and assume directory information is public. It isn’t unless the process was followed.
Emailing records to unverified addresses. Before sending any student record via email, verify that the email address belongs to a person who has a legitimate educational interest or consent has been obtained. Sending grades to a parent at an unverified email address, or to a student’s old email, creates a disclosure risk.
Student data rights beyond FERPA
FERPA is the floor. Several states have passed additional student privacy laws that add requirements — often significantly stricter ones.
State laws in the US. California’s SOPIPA (Student Online Personal Information Protection Act), New York’s Education Law 2-d, and similar laws in other states impose restrictions on how EdTech vendors can use student data that go beyond what FERPA requires. If your institution operates in these states, know the applicable law and ensure your vendor agreements meet the state standard, not just the federal FERPA floor.
COPPA and students under 13. Covered operators must establish a permitted consent route before collecting children’s personal information. School authorization is limited to the permitted educational purpose and requires the necessary notice. A tutoring center cannot assume it has a school’s authority. Review the FTC’s COPPA guidance and Ilmiya’s consent framework.
GDPR for international institutions. Determine whether the processing falls within GDPR’s territorial scope, including an EU establishment or certain activities directed at people in the EU. Student nationality alone does not decide this. Where GDPR applies, establish a lawful basis, honor applicable rights and assess high-risk processing. Rights such as erasure have conditions and exceptions. See GDPR Articles 3, 6, 17 and 35.
Data minimization: collect only what you need
The most underused privacy practice in education is data minimization — the discipline of collecting only the student data you actually need for a defined purpose, and deleting it when that purpose has been served.
Know what you collect and why. Before collecting any student data, answer three questions: What data are we collecting? Why do we need it? How long will we keep it? If you can’t answer all three, you’re collecting data without a policy, which creates liability and increases the harm from any breach.
Data you don’t collect can’t be breached. Every data element you collect is a potential liability. Social security numbers, health information, family income data, disciplinary records — each carries risk proportional to its sensitivity. If you don’t need it to serve the student’s educational interests, don’t collect it. This sounds obvious and is frequently violated: institutions collect data because they can, because a vendor offers to collect it, because it seemed useful once, or because nobody thought to stop.
Build a data inventory. Know where student data lives: which systems hold which types of data, who has access, how it’s protected, and what the retention period is. A data inventory is not a compliance document — it’s a prerequisite for making rational decisions about risk, for responding to data subject access requests, and for knowing what to report in a breach. Institutions that don’t have a data inventory discover what they’re holding when something goes wrong.
Enforce retention schedules. Student records that are no longer needed should be deleted on a defined schedule, not kept indefinitely. Retention schedules are legally required in some jurisdictions and good practice everywhere. Data that has been deleted can’t be breached, can’t be improperly disclosed, and doesn’t create compliance burden. Build the deletion schedule and enforce it operationally.
Vetting EdTech for privacy
The EdTech market moves fast and privacy considerations are frequently secondary to feature appeal. A tool that educators love and students use enthusiastically can still be a privacy liability if it wasn’t designed with student data protection in mind.
Three filtering questions before any procurement. Before investing time in evaluating an EdTech tool, ask these three questions:
- Does the company use student data for advertising or sell it to third parties? If yes, stop here — this is a disqualifying condition.
- Will they sign a data processing agreement (DPA) or data privacy agreement before deployment? If they won’t, stop here — no agreement means no contractual protection for your students.
- Who owns the data you and your students create in the platform? Data ownership should be yours, not the vendor’s.
Read the privacy policy, but look for specific things. Not the whole policy — the policies that matter most for your decision:
- Does the company sell or share student data with advertisers or third parties for commercial purposes?
- Is student data used to train their AI models or improve their product?
- Where is data stored? Is it in jurisdictions with appropriate data protection laws?
- What happens to student data when your contract ends — is there a deletion process, and what’s the timeline?
- What are the breach notification terms — how quickly will they notify you if there’s a security incident?
Check the agreement that applies. A named agreement or program logo is only useful when you can confirm its parties and scope. Ilmiya’s current commitments are set out in its Student Privacy Commitments and DPA. Review those documents and the accepted customer agreement for your institution’s requirements.
Ask for the DPA. A Data Processing Agreement (DPA) is a contract that specifies how a vendor handles data on your behalf. Before deploying any tool that processes student data, request the DPA. It should specify: what data is processed, for what purposes, under what restrictions, with what security measures, and what obligations exist in case of a breach. If the vendor doesn’t have one or is reluctant to sign one, that’s a significant red flag.
Security practices to ask about. Request evidence for encryption and access controls. Ask about recent security testing and how findings were resolved. Review any available independent audit report for its scope and period, then check the subprocessor list to understand which providers handle the information. Record gaps that affect your institution’s requirements.
Free tools carry hidden costs. Consumer-grade tools — even ones with .edu pricing or “free for educators” programs — often have business models built around data. Teacher accounts on consumer platforms may not provide the institutional data governance controls you need. Use institutional accounts with proper agreements rather than personal or free accounts for anything involving student data.
Build a retroactive review process. Most institutions accumulate EdTech tools without a systematic review cycle. Tools that were deployed two years ago under a previous policy may no longer meet current standards. Build an annual review of all tools touching student data: re-verify their privacy policies, re-check their agreements, verify that the tool is still needed and still in use. Tools that fail the review get removed.
Security foundations
Privacy compliance is necessary but not sufficient. The data must also be secure — protected against unauthorized access, theft, and breach. Security is a technical discipline with its own requirements, but there are institutional practices that every organization handling student data should have in place.
Access control. Only staff who need access to student data to do their jobs should have it. A teacher needs access to their students’ records; they don’t need access to every student in the school. An administrative assistant needs access to enrollment information; they don’t need access to disciplinary records. Role-based access controls, enforced by your systems, implement this in practice. When staff leave, revoke access promptly — a former employee’s credentials are one of the most common breach vectors.
Strong authentication. Weak passwords and shared accounts are the simplest vectors for unauthorized access. Require strong passwords, prohibit password reuse across systems, and enable multi-factor authentication for all accounts with access to student records. Single sign-on through a properly configured identity provider centralizes authentication management and makes it easier to revoke access when staff leave.
Encryption everywhere. Student data should be encrypted at rest (protected if a server is physically stolen or compromised) and in transit (protected from interception between systems). These are baseline expectations, not advanced security practices. Any vendor who doesn’t encrypt student data at rest and in transit is not a viable choice.
Incident response. Document who handles a breach and how to assess notice duties. FERPA itself does not require family breach notice, though state law or a contract may. GDPR Article 33 sets a risk-based supervisory notice duty, generally within 72 hours of controller awareness where feasible. Test the response plan. See the Department of Education’s breach guidance and GDPR Article 33.
Vendor security. Assess each vendor against the data it will handle and your institutional requirements. Review the contractual safeguards and the evidence behind its security statements. Ask how it controls staff access and responds to incidents. Resolve material gaps before sharing student data.
No student data on personal devices or accounts. Staff who handle student records through personal email, personal cloud storage, or personal devices create a security gap outside the institution’s control. Establish and enforce a policy that student data stays in institutional systems, on institutionally managed devices, accessed through institutionally managed accounts.
Building an institution students and families can trust
Compliance is the floor. Trust is built above it — through consistent behavior, honest communication, and evidence that the institution handles student information as if it matters.
Be transparent about what you collect and why. Publish clear, plain-language notices about what student data you collect, for what purposes, and with whom it’s shared. Not in dense legal language — in language students and families can actually read. When that information changes, communicate the change proactively, not in an updated privacy policy they’ll never see.
Give students agency where possible. FERPA gives parents and eligible students rights to inspect records and seek amendment under its procedures. Make requests easy to submit and explain how the institution will respond. Let learners see their progress where the service and their permissions allow it.
Handle data access requests promptly and gracefully. A student or parent who asks to see records should be taken seriously, helped through the process, and given access within the statutory timeline. Resistance, delays, or confusion about how to handle the request signals an institution that is not genuinely committed to the rights it’s legally obligated to respect.
Accountability when something goes wrong. Breaches, unauthorized disclosures, and policy violations happen. How an institution responds — transparently, with genuine accountability, with concrete steps to prevent recurrence — shapes the trust relationship far more than whether the incident occurred. Institutions that minimize, obscure, or respond defensively to privacy failures lose trust in ways that take years to rebuild.
Privacy as a design criterion, not an afterthought. The institutions that are genuinely trustworthy don’t treat privacy as a compliance obligation to satisfy — they treat it as a design criterion that shapes every technology decision, every data collection decision, and every vendor relationship. Privacy by design means asking “what data do we need and how do we protect it?” at the beginning of every new initiative, not asking “what did we accidentally collect and what do we have to disclose?” after the fact.
Loading Markdown…
Markdown could not load. or open the raw file.