FERPA Compliance Checklist for Product Teams
FERPA (Family Educational Rights and Privacy Act) governs how student education records are collected, used, and disclosed in educational technology products. EdTech products that violate FERPA risk losing their school and district customers, as FERPA violations can result in the loss of federal funding for educational institutions.
This checklist translates FERPA requirements into actionable product team tasks for building FERPA-compliant education technology.
Template sections
5 sections covering the complete compliance workflow.
Student Education Record Classification
FERPA protects "education records" -- any records directly related to a student that are maintained by an educational institution or a party acting on its behalf. Product teams must classify every data element as an education record, directory information, or non-record. This classification determines consent requirements, disclosure restrictions, and retention obligations.
Education records in our product: student grades, assessment scores, attendance records, behavior reports, IEP documents, and teacher comments on student work. Directory information (may be disclosed without consent per school policy): student name, grade level, enrollment status. Not education records: de-identified aggregate data, teacher-to-teacher communications not in student file, parent contact information maintained for school operations.
Tips
- Classify every data element in your product as education record, directory info, or non-record
- Education record classification applies when data is maintained on behalf of a school
- Directory information policies vary by school district - support per-district configuration
- When in doubt, classify data as an education record and apply full protections
Consent and School Official Exception
FERPA requires consent before disclosing education records, with exceptions. The most relevant exception for EdTech products is the "school official" exception: vendors can access education records without consent if they have a legitimate educational interest and are under the direct control of the school. This requires a contract or agreement specifying the vendor role and data handling requirements.
Our product operates under the school official exception: school district agreement designates us as a school official with legitimate educational interest in student assessment data. Agreement specifies: data used only for assessment delivery and reporting, no data used for marketing, no data sold or shared with third parties, data deleted upon contract termination. Parental consent not required under this exception, but school must include us in annual FERPA notification.
Tips
- Ensure your school district contract explicitly establishes the school official relationship
- Specify in contracts that data is used only for the contracted educational purpose
- Never use student education records for marketing, profiling, or sale
- Include data deletion obligations upon contract termination in every agreement
Data Minimization and Purpose Limitation
Collect only the student data necessary for the contracted educational purpose. Do not collect behavioral tracking, device fingerprinting, or usage analytics beyond what is needed for product functionality. FERPA does not explicitly require data minimization, but state student privacy laws (COPPA, SOPIPA, state-specific laws) do, and school districts increasingly require it in procurement.
Data minimization review: Assessment platform collects student name, grade, answers, and scores (required for assessment function). Removed: browser fingerprinting (not needed), keystroke timing analytics (not needed for assessment), IP address logging (replaced with school-level location). Usage analytics: aggregate only (class-level usage patterns, not individual student tracking). Third-party analytics: Google Analytics removed, replaced with self-hosted analytics without student PII.
Tips
- Conduct a data minimization review for every feature before development
- Remove third-party analytics tools that track individual student behavior
- Use aggregate analytics (class-level, school-level) instead of individual student tracking
- Document the educational purpose for every data element collected
Parent and Eligible Student Rights
FERPA grants parents (and students over 18) the right to inspect education records, request corrections, and consent to disclosures. Your product must support these rights: provide record access, handle correction requests, and manage consent for any disclosures beyond the school official exception.
Parent access feature: parents can view their child records through a parent portal (grades, assessments, attendance). Correction request: parents can submit a correction request through the portal, routed to the school administrator for review and decision. Consent management: for any data sharing beyond the contracted educational purpose, parent consent required with specific disclosure details (what data, to whom, for what purpose). Consent records retained for audit.
Tips
- Build parent record access as a product feature, not a manual report generation process
- Include a correction request workflow routed to school administrators
- Support granular consent management for disclosures beyond the school official exception
- Retain consent records with timestamp, scope, and parent identity for audit
Data Security and Breach Response
FERPA requires reasonable methods to ensure only authorized parties access education records. While FERPA does not specify encryption standards, state student privacy laws and school district contracts typically do. Build security controls appropriate for student data and prepare breach notification procedures that comply with both FERPA and applicable state laws.
Security controls: encryption at rest (AES-256) and in transit (TLS 1.3). Role-based access: teachers see only their students, principals see all students in their school, district admins see all students. Audit logging: all education record access logged with user, student, timestamp, and action. Breach notification: within 72 hours to affected school districts per standard contract terms (state laws vary from 24 hours to 60 days, so we target 72 hours to satisfy most requirements).
Tips
- Implement role-based access aligned to educational roles (teacher, principal, district admin)
- Log all education record access for audit and breach investigation capability
- Target 72-hour breach notification to school districts to satisfy most state laws
- Include security controls and breach notification terms in every school district contract
Copy-paste template
# FERPA Compliance Checklist — EdTech Product Team ## Data Classification - [ ] All data elements classified (education record / directory info / non-record) - [ ] Education records identified and protected - [ ] Directory information configurable per school district policy ## Legal Basis - [ ] School official exception established via district contract - [ ] Contract specifies data use, retention, and deletion terms - [ ] No use of student data for marketing or profiling ## Data Minimization - [ ] Only educationally necessary data collected - [ ] Third-party tracking removed or anonymized - [ ] Analytics aggregate-only (no individual student tracking) ## Parent Rights - [ ] Parent access to student records supported - [ ] Correction request workflow implemented - [ ] Consent management for non-standard disclosures ## Security - [ ] Encryption at rest and in transit - [ ] Role-based access by educational role - [ ] Audit logging for all education record access - [ ] Breach notification within 72 hours
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.