FERPA Compliance Checklist for EdTech Vendors

By Darrell Waldon8 min readUpdated 3/29/2026

If you are searching for a FERPA compliance checklist for edtech vendors, start with the questions university procurement and security teams actually ask before approval. Under the Family Educational Rights and Privacy Act, any vendor that receives, maintains, or accesses personally identifiable information from student education records must comply with the same data handling, disclosure, and consent requirements as the institution itself. That means a signed data processing agreement, restricted data use, documented security controls, and a clear breach notification protocol. Universities that hand off student data to a non-compliant vendor risk losing federal funding. Vendors who get that wrong face contract termination, removal from approved vendor lists, and exposure under state privacy laws. This checklist covers the twelve requirements that come up most often in FERPA procurement reviews — and the answers that flag a vendor as a risk before evaluation even begins.

The Complete FERPA Compliance Checklist for EdTech Vendors

Every university IT and procurement team evaluating an EdTech platform faces the same compliance question: does this vendor handle student data in a way that's FERPA-compliant — and can we prove it? FERPA extends to vendors who access student data on the institution's behalf, treating them as "school officials" subject to the same obligations as university employees. The following twelve-item checklist covers the areas where compliance most commonly fails in EdTech deployments.

Sign a FERPA-compliant data processing agreement (DPA) with each university partner. Universities are required by FERPA to establish annual agreements with any "school official" given access to education records. Your DPA must specify the legitimate educational purpose, restrict re-disclosure, and include breach notification terms. A generic software license or terms-of-service agreement does not satisfy this requirement — the DPA must explicitly reference FERPA and the school official exception under 34 CFR § 99.31(a)(1).
Apply data minimization principles to everything you collect. Request and store only the student data fields that are directly necessary for the educational purpose stated in your agreement. If your application needs a student's name and enrollment status but not their student ID number or disability status, do not request the latter. Data minimization limits breach exposure and simplifies your compliance obligations at every subsequent step.
Prohibit third-party sharing without explicit institutional authorization. Under the school official exception, vendors cannot re-disclose education records to any third party — including analytics providers, advertising networks, or AI training datasets — without the originating institution's explicit written authorization. Your internal data sharing policies, subprocessor agreements, and product architecture must all enforce this restriction technically, not just contractually.
Implement role-based access controls enforced at the platform level. Access to student education records must be limited to users who have a legitimate educational interest in those specific records. Role-based access control (RBAC) must be a technical enforcement mechanism, not merely a policy. Disability services staff should not be able to view financial records; faculty should not have access to accommodation documentation unless directly relevant to a specific student's coursework.
Maintain comprehensive audit logs with sufficient retention. FERPA compliance requires being able to demonstrate who accessed which records and when. Your platform must generate access logs for every interaction with student education records, including reads, exports, and administrative actions. Audit logs must be retained long enough to support your university partners' internal audit cycles — typically a minimum of one to three years depending on the institution's policy.
Encrypt student data at rest and in transit. All personally identifiable student information must be encrypted using current standards: TLS 1.2 or higher for data in transit, and AES-256 or equivalent for data at rest. Encryption keys must be managed separately from the data they protect. Subprocessors (cloud storage providers, database services) must provide equivalent encryption guarantees, which should be documented in your vendor agreements with them.
Establish a breach notification protocol with a 72-hour maximum timeline. Your DPA with each university partner must commit to notifying the institution within 72 hours of discovering any unauthorized access to, disclosure of, or loss of student education records. This includes minor incidents — a misconfigured sharing link, a support ticket that inadvertently exposed student data, or an employee accessing records outside their designated scope. The notification must describe the nature of the incident, the data affected, and the remediation steps taken.
Honor student inspection rights. FERPA gives students the right to inspect and review their own education records within 45 days of a request. If your platform maintains education records on behalf of a university, you must support the institution's ability to fulfill these requests. This may mean providing data export capabilities, responding to institutional subpoenas for student records, or enabling students to view their data directly through the platform interface.
Document legitimate educational interest for every data access pattern. Every category of student data your application accesses must be traceable to a specific, documented legitimate educational interest. This documentation should be reflected in your DPA, your internal data governance policies, and your product engineering decisions. If a proposed new feature would require accessing a new category of student data, that expansion must be authorized by your university partners before implementation, not after.
Never use student data for marketing or advertising purposes. This prohibition is absolute under FERPA. Student education records — including behavioral engagement data, academic performance signals, or demographic information derived from education records — may not be used to target advertising to students, build marketing profiles, or improve products in ways that benefit the vendor commercially rather than the student educationally. This restriction applies even if the data is aggregated or de-identified, if re-identification is reasonably possible.
Establish and enforce data retention limits and deletion schedules. Your DPA should specify how long student data will be retained after the end of the institutional relationship, and what the deletion process looks like. Upon contract termination, all student education records must be returned to the institution or securely destroyed within a defined timeframe — typically 30 to 90 days. You must be able to provide written confirmation of deletion to your university partners. Backups containing student data are subject to the same deletion requirements.
Conduct annual FERPA training for all staff who handle student data. FERPA compliance is not a one-time certification — it requires ongoing staff education. Any employee who has access to student education records must receive annual training covering what constitutes a FERPA-protected record, the permitted disclosure exceptions, the prohibition on unauthorized re-disclosure, and the vendor's internal breach reporting procedure. Training completion should be documented and available for institutional audit.

Part 2: Data Classification and Scope

Before evaluating a vendor's compliance posture, universities need clarity on what data the vendor will actually touch.

Identify what constitutes an education record in this context. Education records under FERPA include any records directly related to a student and maintained by the institution or a party acting on its behalf. This includes grades, accommodation letters, counseling referrals, and behavioral flags — not just transcripts. Confirm whether the vendor accesses individually identifiable student data or only aggregated and anonymized data. A platform that shows cohort-level retention statistics is materially different from one that stores individual accommodation records.

Define the data types explicitly in the vendor agreement — do not rely on general language like "student data." List the specific data fields the vendor will receive, store, or process: name, student ID, accommodation status, LMS engagement metrics, counseling referral records, and so on. Determine whether disability-related data requires additional protections. Accommodation records may be subject to both FERPA and ADA confidentiality requirements. Some institutions treat accommodation data as requiring DSO-only access regardless of FERPA's broader provisions.

Finally, confirm data residency. Where will student data be stored? Does the vendor use subprocessors in other jurisdictions? This matters for institutions with additional state privacy requirements such as California's SOPIPA or applicable provisions of the CCPA.

Part 3: Consent Requirements

Some EdTech implementations require student consent rather than relying on the school official exception — particularly when the vendor's function goes beyond what the institution would normally perform internally, or when the data use is broader than the institutional relationship.

Determine whether the school official exception covers all planned uses. If the vendor will use student data for product improvement, research, or any purpose beyond the immediate institutional function, the school official exception may not apply and student consent may be required. If consent is required, confirm it meets FERPA's written consent standard: signed, dated, specifying the records disclosed, stating the purpose of disclosure, and identifying the parties to whom disclosure may be made. Blanket consent buried in terms of service does not meet this standard.

Confirm the vendor does not condition service on consent to secondary data uses. Vendors who want to use student data for training AI models or building product benchmarks cannot condition the provision of the core service on student consent to those secondary uses. Review the vendor's student-facing privacy policy for accuracy relative to what data is actually collected and how it is used.

Part 4: Access Controls and Role-Based Permissions

FERPA limits disclosure of education records to parties with a legitimate educational interest. In practice, this means EdTech platforms need technical role-based access controls, not just policy-level restrictions.

Confirm that role-based access is enforced at the platform level. Disability services staff should not be able to access student financial records; student affairs staff should not be able to access full accommodation files. Access separation must be enforced technically. Verify that DSO-only data is genuinely scoped to DSO users — accommodation letters, disability documentation, and related records are among the most sensitive data on campus, and access by non-DSO roles should be technically impossible, not merely discouraged.

Review audit logging capabilities. FERPA compliance requires being able to demonstrate who accessed which records and when. Review subprocessor access controls — if the vendor uses subprocessors such as cloud providers, analytics tools, or support platforms, confirm that those subprocessors are bound by the same access restrictions as the primary vendor.

Part 5: Breach Notification and Incident Response

FERPA doesn't prescribe specific breach notification timelines, but institutions are expected to have procedures in place and to notify affected students of unauthorized disclosures. Your DPA should specify how quickly the vendor must notify your institution of a breach — typically 24 to 72 hours — fast enough for the institution to meet its own notification obligations.

The vendor should notify the institution of any unauthorized access to, disclosure of, or loss of student education records, not just large-scale breaches. A credible vendor will have a documented incident response plan, evidence of tabletop exercises, and a named incident response contact. For institutions handling sensitive disability data, vendor cyber insurance coverage is a reasonable procurement requirement. The vendor agreement should also give the institution the right to conduct or commission security audits of the vendor's data handling practices.

What Happens When EdTech Vendors Violate FERPA?

The enforcement mechanism for FERPA violations is significant: the U.S. Department of Education can withhold federal funding from institutions found to have disclosed student education records improperly. Because virtually all U.S. universities depend on federal Title IV funding, this threat creates genuine institutional urgency around vendor compliance. The U.S. Department of Education's Student Privacy Policy Office (SPPO) investigates FERPA complaints and can withhold federal funding from institutions found in violation. While FERPA does not create a private right of action, state laws and contract claims can create significant liability.

From the vendor's perspective, a FERPA violation attributable to the vendor's product — a misconfigured API, an unauthorized data share, or a breach of the DPA's purpose limitation clause — will typically result in contract termination, removal from the institution's approved vendor list, and potential clawback of fees paid. In competitive EdTech markets where university procurement decisions hinge on trust and compliance posture, a single documented violation can damage institutional relationships for years.

Beyond the direct contractual consequences, vendors face exposure under state privacy laws that do carry private rights of action. California's SOPIPA and similar statutes in other states impose obligations on edtech providers that operate independently of FERPA and carry their own enforcement mechanisms. Vendors who operate nationally must maintain compliance postures that address the most stringent state requirements, not just the federal baseline that FERPA establishes.

How OVR IT Maintains FERPA Compliance

OVR IT is built from the ground up with FERPA compliance as a product constraint, not an afterthought. The application's data architecture uses Supabase row-level security (RLS) policies that enforce data isolation at the database layer — no student can query or access another student's records, regardless of how an API call is constructed. This technical enforcement is not supplemented by application-layer checks alone; the database will reject unauthorized queries before they return data. Every student's tasks, grades, goals, and notes are visible only to that student and to institutional users with explicitly granted access.

OVR IT does not sell, license, or share student personally identifiable information with any third party, including advertisers, AI training dataset providers, or product benchmarking services. The product is funded by student subscriptions and institutional licensing agreements, not by monetizing student behavioral data. This is a deliberate architectural and business model decision: building a product for students with ADHD and learning differences means earning and maintaining the trust of both students and the disability services offices that recommend the tool.

For university procurement teams, OVR IT maintains a FERPA-compliant data processing agreement that is available on request as part of standard procurement. The DPA specifies the school official exception as the legal basis for data processing, enumerates the specific data categories accessed, prohibits all secondary data uses, and includes a 72-hour breach notification commitment. Product decisions around feature design — including what data to collect, how long to retain it, and who can access it — are made with data minimization as a first principle. If a feature can be built without storing additional student data, it is built that way.

Frequently Asked Questions

Does FERPA apply to EdTech apps?

Yes. Any application that accesses personally identifiable information from student education records — even if the university is the one granting access — is subject to FERPA requirements. The vendor must be designated as a "school official" with a legitimate educational interest and must operate under a signed agreement with the institution. Self-designation as FERPA-compliant is not sufficient; the institution must formally extend school official status to the vendor in its FERPA policy and in the data processing agreement before any student data is transmitted.

What student data can EdTech vendors collect?

Only data that is directly necessary for the educational purpose stated in the data processing agreement. Vendors cannot use student data for advertising, product improvement without consent, or any purpose beyond what was specified in the DPA. Directory information — such as name, email address, and enrollment status — may be shared unless a student has opted out under FERPA's directory information provisions. Non-directory information, including grades, accommodation status, and disciplinary records, requires either the school official exception or explicit written student consent before disclosure.

How do universities evaluate FERPA compliance in vendors?

Universities typically require vendors to complete a vendor security questionnaire, sign a data processing agreement, and provide evidence of security controls such as a SOC 2 Type II report, ISO 27001 certification, or equivalent. Procurement teams and disability services offices increasingly use FERPA compliance as a vendor selection criterion, particularly for tools that will access accommodation data or integrate with the student information system. Vendors who cannot provide a signed DPA, a subprocessor list, and documented breach notification procedures are typically disqualified before substantive evaluation begins.

Quick Reference: FERPA EdTech Vendor Scorecard

Requirement	Status
Written DPA referencing FERPA	Required before deployment
School official exception documented in institutional policy	Required before deployment
Role-based access controls (technical, not just policy)	Required before deployment
DSO data scoped to DSO roles only	Required before deployment
Subprocessor list disclosed and approved	Required before deployment
Breach notification SLA (72 hours maximum)	Required before deployment
Student data deletion clause	Required before deployment
SSO / SAML 2.0 support	Required before deployment
Audit logging with sufficient retention	Required before deployment
No sale or secondary use of student data	Required before deployment
Data residency confirmation (U.S.)	Required before deployment
Cyber insurance coverage documentation	Recommended
Annual security review / SOC 2 report	Recommended
Annual staff FERPA training with documentation	Required before deployment

Red Flags in Vendor Evaluations

These are the responses that should slow down or stop a procurement:

"We're FERPA-compliant" without specifics. This is a marketing claim, not a legal posture. Ask for their DPA, their subprocessor list, and their breach notification SLA. If they cannot produce these documents, they are not operationally compliant regardless of what their website states.

Aggregated data used for vendor benchmarking without explicit authorization. Some EdTech vendors use student data from multiple institutions to build benchmarks or train algorithms. This may not be covered by the school official exception and requires explicit opt-out provisions at minimum, and opt-in authorization in most interpretations.

No data deletion clause. If a vendor's agreement does not specify what happens to student data upon termination, that is a material compliance gap. Negotiate explicit deletion requirements — including backup destruction and written confirmation — before signing any agreement.

SSO / SAML support "on the roadmap." This means students will authenticate with separate credentials, creating friction and increasing the likelihood of weak password practices. Identity management happening outside institutional systems is a significant compliance and security risk. Require SSO before deployment.

Vague data residency answers. "Our data is secure" is not a data residency answer. Ask specifically: what cloud provider, what regions, what subprocessors, and what controls prevent data from leaving those regions. Institutions with state privacy obligations beyond FERPA need specific, documented answers.

OVR IT is built for university FERPA compliance requirements from the ground up — student data isolated by row-level security, no PII sold or shared with third parties, role-scoped individual records, SAML 2.0 SSO, and a signed DPA available as part of standard procurement. See the IT & procurement overview or contact us to request security documentation.

#FERPA #EdTech procurement #university IT #compliance #data privacy #disability services

Share on Twitter Share on LinkedIn

ADHD College Dropout Rate: What the Real Numbers Show

Sourced statistics on ADHD college dropout, retention, and graduation rates — and the executive-function challenges driving them.

8 min

How Universities Support ADHD Students: What Disability Services and Student Affairs Teams Can Do

A practical guide for disability services coordinators, student affairs staff, and university administrators supporting ADHD students, from accommodations to retention signals and cross-campus follow-through.

14 min

Study Techniques & Tools

Liked this? OVR IT is built on the same research.

OVR IT is an ADHD-first study planner that helps students start, stay on track, and recover when they fall behind. Free to use, no setup required.

Start Free See features →

FERPA Compliance Checklist for EdTech Vendors | 2026 Guide