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 — has been federal law since 1974. It governs who can see student education records, who can release them, and what parents and students can do about it. Almost every US school and university receives federal funding, and almost all are therefore subject to FERPA.
What FERPA covers. FERPA protects “education records” — any record that directly relates to a student and is maintained by the institution. This includes grades, transcripts, disciplinary records, class lists, and most communication that references a student’s academic performance or behavior.
It does not cover:
- Sole possession records — notes a teacher keeps privately and shares with no one
- Law enforcement records — maintained by campus security for law enforcement purposes
- Employment records — when a student is also employed by the institution
- Alumni records — information about a person after they’ve left the institution
The consent requirement. The core rule: the institution cannot disclose education records to anyone outside the institution without written consent. The exceptions are specific and narrow.
Who can see records without consent:
- School officials with legitimate educational interest — teachers, counselors, administrators who need the information to do their jobs. Not every staff member at the institution qualifies — only those with a specific, current need.
- Other schools — when a student transfers, to facilitate enrollment. This is a narrow transfer exception, not a general permission to share.
- Authorized representatives of state and federal education agencies auditing federally funded programs.
- Financial aid processing — institutions that need student records to determine aid eligibility.
- Parents of dependent students (as defined by the IRS) — but only until the student turns 18 or enrolls in post-secondary education. After that, FERPA rights transfer to the student. A parent calling about their adult college student’s grades is asking for something you cannot give without the student’s written consent, regardless of who pays tuition.
- Genuine health or safety emergencies — a narrow exception requiring an articulable, specific threat. “The student’s parent wants to know if they’re okay” does not qualify.
The disclosure log. Every time you disclose records to someone outside the institution (other than through the named exceptions above), you must record it — who received the information, their legitimate interest, and the date. Students have the right to see this log. This requirement is frequently overlooked; many institutions don’t maintain it. Keep it current and accurate.
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. Posting grades by student name or student ID in any visible form — on a physical bulletin board, in an email to the class, in a shared spreadsheet, in a public learning management system forum — violates FERPA. Aggregate statistics (“the class average was 74%”) are fine. Individually identifiable scores are not. This includes seating charts posted in hallways and honor roll boards that display names next to grades.
Talking to the wrong parent. In custody situations, both parents generally retain FERPA rights unless a court order specifically removes one parent’s rights. If a custody order restricts a parent’s rights, get a copy and keep it in the student’s file. Acting on verbal claims about custody arrangements without documentation is a FERPA risk. For post-18 students, no parent has automatic access without the student’s consent.
Third-party tools without written agreements. Using any platform, app, or service that processes student data requires that vendor to have a written agreement restricting how they can use that data. Using a “free” consumer app that processes student data without a school official agreement — even one the students love — is a FERPA violation. Free products are often free because the business model involves user data. If the vendor hasn’t signed a data processing agreement that restricts them from selling or using student data for their own purposes, don’t use the tool with student data.
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. The Children’s Online Privacy Protection Act requires verifiable parental consent before collecting personal information from children under 13. If any digital tool you use with students under 13 collects personal information, COPPA compliance must be established before deployment. Check whether the tool has a formal COPPA compliance program and whether your use case falls within its scope. Classroom exceptions exist for school-authorized tools used for educational purposes, but the conditions are specific.
GDPR for international institutions. If your institution enrolls students from the EU, the General Data Protection Regulation applies to the personal data of those students. GDPR requirements are stricter than FERPA in several important ways: they require a lawful basis for processing personal data (consent, legitimate interest, or legal obligation), they give individuals the right to erasure (“right to be forgotten”), they require data protection impact assessments for high-risk processing, and they impose 72-hour breach notification requirements to supervisory authorities. If you have EU students, your data practices need to be reviewed against GDPR requirements, not just FERPA.
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?
The Student Data Privacy Consortium. The SDPC maintains a list of vendors who have signed the National Data Privacy Agreement (NDPA) — a standardized contract that establishes clear data protection requirements. Vendors who have signed are not automatically safe, but it’s a signal of at least minimum commitment to these practices. Ilmiya is a signatory.
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. Beyond the privacy policy, ask vendors about: SOC 2 Type II certification (audited security controls), penetration testing frequency and recency, encryption standards (at rest and in transit), access control practices, employee background check requirements, and subprocessor list (who else touches your data). A vendor who can’t answer these questions or won’t provide documentation doesn’t have their security house in order.
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. What happens when something goes wrong — a breach, an unauthorized disclosure, a lost device with student data on it — should be defined before it happens, not improvised in the moment. Know who gets notified, in what order, within what timeframe. FERPA and most state laws require notification of affected families in breach situations. GDPR requires notification to the supervisory authority within 72 hours of discovering a breach. Have the plan documented, and test it at least annually.
Vendor security. Your security is only as strong as your weakest vendor. Any vendor that handles student data should be able to provide evidence of their security practices: SOC 2 Type II certification, penetration testing results, encryption standards, and employee background check requirements. Vendors who can’t provide this documentation shouldn’t be trusted with 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 students the right to inspect and amend their records. Programs that actively enable students to see their own data — their learning records, their engagement history, their assessment results — tend to build more trust and produce more engaged students than those that treat data as exclusively institutional property.
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.