EdTech FERPA compliance: what vendors get wrong and regulators notice
Sienna VanceApril 29, 2026
Key takeaways
The school official exception under 34 CFR 99.31(a)(1) requires a written agreement, a scoped legitimate educational interest, and direct school control over the vendor's use of records. Vendors that invoke the exception without meeting all three conditions are not in a gray area — they are outside FERPA's authorization entirely.
In EdTech vendor gap analyses, the most consistently failed control is data deletion: vendor agreements specify one retention timeline, product defaults implement a different one. The gap is a process failure between legal and engineering, not a policy omission.
California SOPIPA and New York Education Law 2-d impose independent obligations on EdTech vendors that go beyond FERPA, including targeted advertising prohibitions and a parents' bill of rights. Vendors operating nationally cannot treat state law as a FERPA supplement.
FERPA allows schools to provide consent on behalf of parents for school-assigned EdTech tools under the school official exception, but only if the vendor collects no data beyond what the school authorizes. Behavioral analytics or third-party data sharing outside the agreement scope breaks this substitution and requires direct parental consent under COPPA.
District procurement teams and regulators investigating breaches request penetration test reports, data flow diagrams, subprocessor lists, and deletion verification documentation. Vendors that cannot produce these artifacts quickly are at a disadvantage regardless of what their privacy policies say.
TL;DR
Most EdTech vendors treat FERPA as a contract problem. Sign the right language with the district, invoke the school official exception, and compliance is handled. That framing is wrong. The exception has three operative conditions, and most vendor agreements satisfy them only on paper. The actual technical controls — deletion schedules, subprocessor agreements, data flow boundaries — frequently do not match what the contract says. Regulators and district counsel know this. Increasingly, they check.
The agreement said 90 days. The database said two years.
A mid-sized EdTech platform serving K-12 districts across seven states had signed data processing agreements with all of its school clients. The agreements specified that student data would be deleted within 90 days of contract termination. The platform's product team had set default data retention to two years when they built the feature in 2019. Nobody had updated that default when the legal templates were revised in 2021. When a district's data protection officer requested deletion verification documentation after their contract ended, the vendor's engineering team discovered the discrepancy. The data had not been deleted. It had been sitting in production databases for 14 months past the contractual deadline, covered by a FERPA agreement that the product had never actually implemented.
The failure was not that the vendor lacked a privacy policy or a data retention clause. Both existed. The failure was that legal and engineering had never been in the same room to verify that what was agreed to was operationally implemented. That gap — between documented compliance and actual system behavior — is where FERPA exposure lives for EdTech vendors. It is not a legal problem. It is a process problem that regulatory frameworks are not built to surface.
What the school official exception actually requires
The school official exception under 34 CFR 99.31(a)(1) is the primary mechanism by which EdTech vendors legally access education records without individual parental consent. The regulation allows disclosure to school officials who have a legitimate educational interest in the records. Vendors qualify as school officials if they meet three conditions: they perform a function that the school would otherwise use its own employees to perform, they are under the direct control of the school with respect to the use and maintenance of education records, and they are subject to FERPA's redisclosure prohibitions.
All three conditions must be satisfied. Most EdTech vendor agreements address them in general terms without specifying what they mean operationally. 'Legitimate educational interest' gets defined as 'providing the contracted services' without specifying which student data is actually necessary for those services. 'Direct control' is described in one sentence without explaining what control mechanisms the school actually exercises. 'Subject to redisclosure prohibitions' appears as a clause without identifying what third parties the vendor uses and whether those parties have signed comparable agreements.
When a school district's legal counsel reviews a vendor agreement closely — which happens more frequently now than it did five years ago — this vagueness becomes a problem. Counsel cannot confirm that the exception is properly established because the agreement does not contain enough specificity to evaluate. Some districts are now requiring vendors to produce data flow diagrams and subprocessor lists before execution. Vendors that have not mapped their own data flows are unable to provide what is being requested.
The redisclosure piece is where the most technical complexity lives. A vendor that uses a third-party analytics platform, a cloud hosting provider, a customer support tool, or a logging service that handles student data has disclosed education records to those subprocessors. Each of those disclosures needs to be authorized under the original agreement or covered by the subprocessors' own qualifying agreements with the school. In practice, most vendor agreements name the primary vendor and are silent on subprocessors.
Example
In gap analysis work with an EdTech SaaS platform, the data flow mapping exercise revealed that student assessment data was being processed by three services not named in any district agreement: a cloud logging provider that stored full API request bodies including student identifiers, a third-party error tracking tool that captured stack traces containing student session data, and an analytics service used internally by the vendor's product team to understand feature usage. None of the three had signed agreements with the districts. None were named in the vendor's privacy policy. All three were receiving education records under a school official exception that did not cover them.
Subprocessor audits are not complicated to run but they require someone to look at data flows at the infrastructure level, not the policy level. Reviewing what a privacy policy says about subprocessors tells you what the vendor intended to document. Reviewing network egress, logging configurations, and third-party SDK integrations tells you what is actually happening.
What gap analyses actually find in EdTech environments
Assessment base: Findings drawn from Vulnox FERPA gap analyses and compliance assessments of EdTech SaaS vendors, 2023-2024.
Deletion schedules that exist in contracts and not in products
In FERPA-scoped gap analyses of EdTech platforms, the gap between contractual deletion timelines and actual product behavior is the most consistently present finding. Vendor agreements specify retention periods. Product default configurations implement different retention periods. The discrepancy typically originates from contracts being updated without corresponding engineering tickets, or from engineering teams setting defaults during initial build that were never revisited when the legal template evolved.
Under FERPA, retaining education records past the contractually agreed deletion date is not a minor administrative issue. It is unauthorized retention of protected records. If a breach occurs during that window, the vendor is holding data they were not entitled to hold. District counsel and regulators will have access to both the agreement and the system logs. The gap will be visible.
Subprocessors not covered by qualifying agreements
In the majority of EdTech vendor assessments where data flow mapping was performed, at least one third-party service receiving student data was not named in any school agreement and had not signed its own qualifying FERPA agreement with the districts. The services involved were typically infrastructure components: logging providers, error trackers, monitoring tools. Not marketing platforms. The vendor's legal team was often unaware that these services were receiving student data.
The school official exception does not transfer automatically to subprocessors. Each disclosure is a separate FERPA event. A vendor that shares education records with an unnamed third party has made an unauthorized disclosure regardless of whether that disclosure was intentional, regardless of what that third party does with the data, and regardless of how the vendor characterizes the relationship.
COPPA compliance assumed from FERPA authorization
EdTech platforms serving K-12 students frequently treat school-provided FERPA consent as satisfying COPPA requirements for students under 13. That substitution is valid only when the vendor collects exclusively what the school authorizes for educational purposes. Platforms that run product analytics, behavioral tracking, or any data collection beyond the core educational function cannot rely on school consent for COPPA purposes and require a separate parental consent mechanism.
COPPA enforcement by the FTC does not require a breach. The data collection practice itself is the violation. Platforms that have been operating under the assumption that school consent covers all data collection are exposed even if no data has been misused. In assessments where this gap was identified, the remediation required product changes, not just policy updates.
State law obligations mapped to FERPA rather than evaluated independently
Vendors operating nationally frequently build their compliance programs around FERPA and treat state student privacy laws as additive requirements they will address when a specific state requires it. California SOPIPA, New York Education Law 2-d, and similar state statutes impose obligations that are not implied by FERPA compliance — advertising prohibitions, data sale restrictions, parents' bills of rights requiring specific contractual commitments. These require independent evaluation.
A vendor that is FERPA-compliant and SOPIPA non-compliant is non-compliant. The state law does not defer to the federal standard. Vendors that have not mapped state obligations separately from FERPA have compliance gaps in every state where those laws apply, regardless of how solid their FERPA program is.
The privacy policy that made things worse
Common belief
A detailed, publicly posted privacy policy demonstrates FERPA compliance and provides protection if a regulatory question arises. More specificity is better. Documenting data practices thoroughly shows good faith.
What we found
In gap analysis work that included a documentation audit alongside technical assessment, discrepancies between stated privacy practices and actual data handling appeared in the majority of engagements. The most common: retention periods stated in policy did not match product configuration; subprocessors used in production were not listed in the policy; data minimization commitments were not enforced at the data model level.
Privacy policies are public documents. Regulators, district counsel, and plaintiff attorneys read them. A privacy policy that accurately describes data practices that are not FERPA-compliant is a documented admission. A policy that inaccurately describes data practices — overstating protections that are not technically implemented — creates a second layer of exposure: the FERPA violation plus a misrepresentation claim.
In one review, an EdTech vendor's privacy policy stated that student data was never used for advertising or product improvement. The vendor's product team was running A/B tests on feature engagement using student session data. The policy had been written by legal without a technical audit of what the product actually did with data. The mismatch between the policy and the practice was not caught until a district's legal counsel requested documentation during a renewal negotiation.
The FERPA-specific problem is that vendors write privacy policies to satisfy a documentation requirement rather than to accurately describe their data architecture. The policy is reviewed by legal. The data architecture is built by engineering. The two teams do not regularly compare notes. The policy describes an intended state. The product implements an actual state. Those states diverge over time as the product evolves and the policy does not.
What vendors believed before the gap analysis
'We have a signed DPA with every district. That covers our FERPA obligations.'
Root cause:A Data Processing Agreement establishes the legal framework. It does not verify that the technical implementation matches the legal commitments. Agreements that specify deletion timelines, data minimization requirements, and subprocessor obligations are only as useful as the underlying product behavior. Vendors that sign strong DPAs and then do not audit whether their systems comply with those DPAs have documentation without compliance.
'Our platform is COPPA-compliant because our school clients provide consent on behalf of parents.'
Root cause:School-provided consent under FERPA's school official exception substitutes for parental consent under COPPA only for data collection that is directly related to the school's educational purpose and authorized by the school. Any data the platform collects beyond that scope — analytics, behavioral tracking, product improvement data — requires direct parental consent. The substitution is not a blanket authorization for all data collection from students under 13.
'We're compliant in California because we comply with FERPA, and FERPA is stricter.'
Root cause:FERPA and California SOPIPA address different things. FERPA regulates access to and disclosure of education records. SOPIPA prohibits specific uses of student data — targeted advertising, sale of student data, building profiles for non-educational purposes — that FERPA does not address. An EdTech vendor can be fully FERPA-compliant and be violating SOPIPA because a feature uses student engagement data to inform advertising targeting. The frameworks are not on the same scale. They regulate different behaviors.
Where EdTech FERPA programs fail to look
Logging and observability infrastructure
EdTech vendors focus FERPA compliance review on their primary application database and API. Logging systems, error trackers, and observability platforms receive far less scrutiny. These systems frequently receive student data — identifiers in API logs, session tokens in error traces, behavioral events in monitoring streams — that is not captured in data flow documentation and not covered by school agreements. Because these systems are infrastructure rather than product features, they fall outside the compliance review scope. They do not fall outside FERPA's scope.
Contract terms that legal agreed to but engineering did not implement
The gap between legal commitments and technical implementation is structural in most EdTech organizations. Legal teams negotiate contracts. Engineering teams build products. The process for verifying that contract terms are technically implemented does not exist in most organizations below enterprise scale. Retention timelines, data minimization requirements, and deletion verification obligations are the categories where this gap is most consistently present.
Staff access controls after contract termination
Vendor agreements address what happens to student data after contract termination. They rarely address whether vendor staff access to that data is revoked at contract end. In technical assessments, former client data remaining accessible to vendor support and engineering staff after contract termination appears with regularity. The data is flagged for deletion. The access controls are not updated until deletion runs. That window — which can be weeks — is unauthorized access to education records.
Third-party features built on student data
EdTech platforms frequently add features that use student data as a signal: engagement scoring, at-risk student identification, learning pathway recommendations. These features are built by product teams as educational functionality. Whether they constitute authorized uses under the school official exception — whether they serve a legitimate educational interest as defined in the agreement — is a legal question that the product team does not typically ask before building. The feature launches. The FERPA analysis happens later, if at all.
Where FERPA enforcement for EdTech vendors is heading
Within two years, at least one EdTech vendor will face a significant FERPA-related enforcement action or class action centered on subprocessor disclosure rather than breach notification, establishing that the school official exception requires affirmative subprocessor authorization in vendor agreements.
District procurement practices are becoming more technically sophisticated. Legal counsel reviewing vendor agreements are asking for subprocessor lists and data flow diagrams as standard due diligence. The gap between what vendors have documented and what their infrastructure actually does is large and increasingly visible to sophisticated buyers. When a district or a regulator connects that gap to a specific data handling incident, the legal theory — unauthorized disclosure to unnamed subprocessors — is clear and supported by the regulatory text. The first significant action on this theory will sharpen what 'school official exception' compliance requires for the rest of the market.
Confidence: highNo significant enforcement action or class action centered on subprocessor disclosure in EdTech by end of 2027, or first action centers on a different FERPA theory.State student privacy laws will create a compliance bifurcation in EdTech within 18 months, where vendors serving California and New York districts maintain materially different data architectures than vendors serving districts in states without equivalent laws, increasing compliance cost for nationally operating vendors.
California SOPIPA, New York Education Law 2-d, and the pipeline of state-level student privacy legislation impose obligations that require product changes, not just policy changes. Advertising prohibition and data sale restriction compliance cannot be achieved through contract language alone — they require features to be built or removed. Vendors operating nationally cannot build one product that satisfies all state requirements without making architecture decisions that reflect the most restrictive state standards. As enforcement of state laws increases, vendors will face pressure to bifurcate or to build to the highest standard nationally.
Confidence: mediumNo significant state-level EdTech enforcement by mid-2027, or vendors find a single architecture that satisfies all state requirements without bifurcation.
Why FERPA compliance programs are structured wrong
EdTech vendors build FERPA compliance programs that are optimized for contract negotiation, not for regulatory defense. The output of the program is a signed DPA and a privacy policy. Those documents are legible to district procurement. They are much less useful when a regulator opens an investigation or a district's counsel starts asking technical questions.
The underlying problem is that FERPA compliance is treated as a legal function when it is, at its core, a technical one. The school official exception is satisfied or not satisfied based on what the product actually does with data: whether it retains records past agreed timelines, whether it discloses to unauthorized subprocessors, whether it collects beyond what the school authorized. These are engineering questions. Legal teams write policies. Engineering teams implement systems. The policies describe intended behavior. The systems implement actual behavior. Without a process that connects these two — a technical audit of whether what was agreed to is what is running — the compliance program is documentation without substance.
Regulators and district counsel are getting better at asking the technical questions. Vendors that have built FERPA programs around documentation are increasingly meeting counterparts who want to see the data flow diagram, not the privacy policy.
Counterargument
The counterargument is that technical audits are expensive and that smaller EdTech vendors do not have the resources to run ongoing compliance verification across their entire infrastructure. A startup serving 20 districts cannot maintain a security operations function. That argument has genuine force. But the cost comparison is between the ongoing cost of verification and the incident cost of a FERPA gap discovered during a district renewal negotiation or a regulatory investigation. The second cost is not hypothetical. Districts are terminating vendor relationships over compliance documentation failures. The question is not whether verification is cheap. It is whether it is cheaper than the alternative.
One thing to do this week
Pull your most recent signed DPA with a school district and find the data deletion clause. It specifies a timeline — typically 30, 60, or 90 days after contract termination. Then ask your engineering team what the actual data retention configuration is in your production database for that district's data. If those two numbers match, you have evidence that your legal commitments are technically implemented in at least one area. If they do not match, you have found a gap that exists in every district agreement you have signed, and you have found it before a regulator or district counsel did. That is the conversation to have this week: not with legal, but with engineering.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideHIPAA Official Homepage
HIPAA compliance official siteOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
When does FERPA actually apply to an EdTech vendor?
FERPA applies to EdTech vendors when they receive education records from a school or district, typically under the school official exception. That exception requires a written agreement, a legitimate educational interest scoped to specific functions, and a prohibition on re-disclosure. Vendors that store or process student data without a qualifying agreement are not in a gray area — they are outside the exception entirely and in direct violation if they hold protected records.
What does the school official exception actually require from vendors?
The school official exception under 34 CFR 99.31(a)(1) requires that the vendor perform a function that the school would otherwise use its own employees to perform, is under direct control of the school with respect to the use and maintenance of education records, and is subject to FERPA's redisclosure prohibitions. Most EdTech vendor agreements describe these requirements in general terms but fail to specify which functions qualify, which data is in scope, and what 'direct control' means operationally. Regulators and district counsel read these agreements carefully. Vague language creates exposure.
What is the most commonly failed FERPA control in EdTech vendor assessments?
In Vulnox gap analysis work with EdTech vendors, the most consistently failed area is data retention and deletion. Vendor agreements specify retention timelines. The actual deletion schedules in the product are different — usually longer — because engineering teams implemented defaults that were never updated to match contract terms. The gap is not intentional. It is a process failure: legal agreed to terms that product never implemented.
How do California and New York student privacy laws change what EdTech vendors must do?
California's Student Online Personal Information Protection Act (SOPIPA) prohibits targeted advertising using student data, sale of student data, and building profiles of students for non-educational purposes — requirements that go beyond FERPA. New York Education Law 2-d imposes data security requirements, breach notification timelines, and a parents' bill of rights that vendors must contractually commit to. Vendors operating nationally cannot treat these as FERPA supplements. They impose independent obligations that require separate compliance mapping.
What evidence do regulators and district legal teams actually request from EdTech vendors?
District procurement teams and their counsel increasingly request penetration test reports, data flow diagrams showing every system where student data is processed or stored, deletion verification documentation, and subprocessor lists with their own data handling terms. Regulators investigating a breach request access logs, incident timelines, and evidence that the vendor agreement was in place before data was accessed. Vendors that cannot produce these artifacts quickly are at a significant disadvantage regardless of what their policy documents say.
How does COPPA interact with FERPA for K-12 EdTech platforms?
FERPA and COPPA overlap when a platform serves students under 13. FERPA allows schools to provide consent on behalf of parents for school-assigned tools under the school official exception, effectively substituting school consent for parental consent under COPPA. But this only works if the school's use of the platform is purely educational and the vendor does not collect data beyond what the school authorizes. Platforms that run behavioral analytics, serve contextual ads, or share data with third-party services outside the school agreement scope cannot rely on school consent for COPPA compliance and need direct parental consent mechanisms.
What is a realistic timeline for an EdTech vendor to close FERPA compliance gaps?
Based on gap analysis engagements, vendors with documented policies but weak technical controls typically need 60 to 90 days to close the highest-priority gaps: updating deletion schedules to match contract terms, auditing subprocessor agreements, and implementing data flow documentation. Vendors that lack foundational documentation — no data inventory, no written agreements with schools, no retention policy — need longer, closer to six months, because the legal and product work must run in parallel. The blocker is usually internal alignment between legal, product, and engineering, not the technical remediation itself.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.