FERPA and EdTech Vendors: The Compliance Gaps Schools Cannot Fill for You

Schools execute data processing agreements with EdTech vendors, designate them as school officials under FERPA, and route student information through platforms built and operated by private companies. What those agreements cannot do — despite what many vendors implicitly rely on — is transfer the legal compliance obligation for COPPA consent from the vendor to the school. The FTC made this precise point in its 2023 enforcement action against Edmodo, rejecting as "nonsensical" the platform's terms of service provision telling teachers they were "solely responsible for complying with COPPA." The enforcement outcome: deletion of machine learning models trained on improperly obtained student data. The compliance gap between what FERPA permits schools to authorize and what COPPA requires vendors to independently satisfy is where EdTech companies most often find themselves exposed — and where the regulatory landscape is actively shifting.

FERPA Basics for EdTech Developers: Who It Covers and What It Protects

If you build software for schools, you have almost certainly encountered the phrase "FERPA compliant." What the phrase rarely explains is the foundational legal architecture it references — and understanding that architecture is the first thing any EdTech developer needs to do before assessing their compliance exposure. Start with the correct framing: FERPA is a school law, not a vendor law. The compliance obligation runs to the educational institution, not to the companies it buys software from. Your obligations under FERPA are derivative, not independent — they exist only because of a contractual relationship with the school that places you within a specific statutory exception.

Under 20 U.S.C. § 1232g and 34 CFR Part 99, the Family Educational Rights and Privacy Act conditions federal funding on compliance by educational agencies and institutions. The statute imposes no direct compliance obligation on third-party vendors and creates no private right of action against them. An EdTech company that receives student data from a school does so because the school has chosen to treat that vendor as a "school official" under a specific regulatory exception — and that exception comes with conditions your contract must reflect. If there is no contract, or if the contract does not satisfy those conditions, the school is violating FERPA, not you — but the downstream consequences flow to your relationship with the school and, increasingly, to state law enforcement against the vendor directly.

What Counts as an Education Record

The threshold question for any data your product touches is whether it constitutes an "education record" under 34 CFR § 99.3. The definition is broader than most developers expect: an education record is any record that is (1) directly related to a student and (2) maintained by an educational agency or institution, or by a party acting for or on behalf of the agency. Grades, transcripts, attendance records, disciplinary files, course schedules, financial aid records, and health information maintained by the school all fall within the definition.

The regulation carves out four categories of records that are not education records: sole possession records (a teacher's personal notes not shared with anyone else), law enforcement unit records created and maintained by a campus law enforcement unit for a law enforcement purpose, employment records for individuals whose relationship to the school is purely as an employee, and treatment records maintained by a physician or psychologist solely for treatment purposes. If your product is a note-taking tool for teachers, the teacher's personal drafts may not be education records — but the moment those notes are shared into a system accessible to other school staff, the exclusion likely disappears.

The PII Definition: "Alone or in Combination"

Even when individual data elements seem innocuous, FERPA's definition of personally identifiable information can transform them into regulated data. Under 34 CFR § 99.3, PII includes direct identifiers — student name, student ID number, social security number, biometric records — but also indirect identifiers such as date of birth, place of birth, and mother's maiden name. More significantly, the definition captures any information that, "alone or in combination," is linked or linkable to a specific student.

That "alone or in combination" language is where EdTech analytics products most frequently create compliance risk they do not recognize. An application that stores a student's grade level, school name, course enrollment, and birth month may not store any field that is independently identifying — but the combination can make a student uniquely identifiable, particularly in smaller schools or in specialized programs with small cohorts. If your product generates behavioral analytics, engagement scores, learning assessments, or any kind of per-student output that is not genuinely de-identified, you are working with FERPA-regulated data whether or not you call it that.

The Two Tracks: School-Mediated vs. Direct-to-Consumer

The most important jurisdictional question for any EdTech product is which track it is on. Track one: the school purchases your product and deploys it to students through its own account provisioning and data infrastructure. In that scenario, student data flows from the school to your product, and FERPA applies because the school is disclosing education records. Your compliance obligations are derivative of that relationship, and they are governed by the school official exception — which is covered in detail in the next section.

Track two: students or parents access your product directly, without the school acting as an intermediary. In that scenario, FERPA does not apply, because the school is not disclosing any education records to you. The Department of Education has confirmed that data collected directly from a student by a vendor acting outside any school contract is not an education record disclosure and falls outside FERPA's scope. What does apply, if your product is directed at children under 13, is the Children's Online Privacy Protection Act — a federal law with its own consent requirements, enforcement mechanisms, and a 2023 enforcement action against an EdTech company that should be required reading for any developer in this market.

Many EdTech products operate on both tracks simultaneously — a school-licensed version and a consumer-facing app — which is precisely where compliance becomes complicated. A product that is FERPA-governed when a student logs in through the school's SSO and COPPA-governed when the same student logs in from home through a parent-created account is subject to two distinct legal regimes at the same time, and the compliance mechanisms for each are different. Getting the track identification right is the prerequisite for everything else. The sections that follow examine each compliance layer in detail.

The School Official Exception: How EdTech Vendors Plug Into It (and Its Limits)

The school official exception is the legal mechanism that allows schools to share student education records with EdTech vendors without obtaining prior parental consent. It is also the provision that most EdTech companies misunderstand, misapply, or quietly violate once their commercial interests diverge from their educational mission. Understanding the exception's three-element structure is not optional for any vendor receiving student data — it is the baseline for determining whether your data access is lawful at all.

The Three-Element Test

Under 34 CFR § 99.31(a)(1)(i)(B), outside parties — including contractors, consultants, and technology vendors — may qualify as "school officials" with legitimate access to education records only when all three of the following conditions are met:

• Institutional function: The vendor performs a service or function that the school would otherwise use its own employees to perform. An LMS provider substitutes for the school's own course management infrastructure. An assessment platform substitutes for in-house testing administration. A product that does something the school would never do with employees — like targeted advertising or commercial profile-building — fails this element on its face.
• Direct control: The vendor operates under the school's direct control with respect to the use and maintenance of education records. This means the school, not the vendor, determines what data is accessed, for what purpose, and under what limitations. A vendor that collects data beyond the scope of the school contract, or that uses data for its own product development without school authorization, is not under the school's direct control.
• Use and redisclosure limitations: The vendor is subject to the requirements of 34 CFR § 99.33(a), which prohibits using or redisclosing education records for any purpose other than the purpose for which the disclosure was made. This requirement must be reflected in the written agreement between the school and the vendor.

The Department of Education's Student Privacy Policy Office has further clarified that school officials may access only those education records in which they have a "legitimate educational interest" — meaning access must be tied to the specific educational function being performed, not to the vendor's own product objectives. Schools are required to use reasonable methods to ensure that school officials, including vendors, obtain access only to records in which they have that legitimate interest. In practice, this means overly broad data access provisions in school contracts — provisions that give the vendor access to entire student databases rather than the specific fields needed for the contracted service — are not compliant with the exception's requirements.

Where Vendors Cross the Line

The most common way EdTech vendors violate the school official exception is by using student data received under a school contract for purposes that serve the vendor's commercial interests rather than the school's educational mission. Training machine learning models on student interaction data, improving non-school-facing product features, generating aggregate analytics sold to third parties, and conducting behavioral profiling for product development purposes are all uses that fall outside the scope of what the exception permits. The exception permits data use for the specific institutional function the vendor is performing under the school contract — nothing more.

The structural problem, which researchers and advocacy organizations have documented extensively, is that FERPA provides no mandatory contract requirements and no clear regulatory definition of "direct control." The Public Interest Privacy Center has noted that there are no standard security requirements that EdTech vendors must meet before receiving student data, and no requirement that schools have written contracts with all vendors they use. This creates a gap where vendors can nominally claim school official status while operating with data practices that would never satisfy the exception's requirements if subjected to scrutiny.

The Enforcement Reality — and Why It Doesn't Mean What You Think

Here is a fact that surprises many EdTech counsel: the Department of Education has never withheld federal funding from a school due to a FERPA violation. The SPPO's enforcement mechanism — withdrawal of federal funding — is theoretically available but has never been used. The Student Privacy Policy Office can also impose a five-year bar prohibiting a vendor from receiving student data from any school that receives federal funds, but this remedy has similarly not been deployed in a publicized enforcement action against an EdTech vendor to date.

This enforcement gap is not a green light. It is the reason state law enforcement and FTC jurisdiction have become the operative accountability mechanisms for EdTech data practices. California, New York, and Colorado have enacted vendor-direct data privacy statutes that impose obligations regardless of FERPA's enforcement posture. And the FTC — which enforces COPPA and has broad authority over unfair or deceptive trade practices — has demonstrated that it will act where FERPA enforcement has not.

Edmodo: The Precedent Every EdTech Developer Needs to Know

The FTC's 2023 enforcement action against Edmodo is the controlling case for the data practices this section describes. Edmodo was a school-facing EdTech platform that received student data under school agreements — precisely the school official exception framework — and then used that data for commercial purposes including behavioral profiling and targeted advertising. When the FTC challenged these practices, Edmodo's defense was that its Terms of Service had told teachers they were "solely responsible for complying with COPPA." The FTC found this argument "nonsensical" and flatly rejected it.

The Edmodo settlement established several compliance benchmarks that now function as the de facto floor for EdTech data practices:

• Data retention must be limited — the Edmodo order required a one-year maximum retention limit for student data
• School agreements must specifically describe all personal information collection and use — generic data processing terms are insufficient
• Vendors must post clear privacy notices before collecting children's data — not in terms of service, but in accessible, pre-collection notice
• Models and algorithms trained on improperly obtained children's data must be deleted — including commercial AI products built on that training data

That last point deserves emphasis: the FTC required Edmodo to delete machine learning models and algorithms that had been trained on student data obtained without proper consent. For any EdTech company building AI-powered features, this is not a hypothetical risk. If the underlying training data was not properly authorized under the school official exception — or if school authorization was defective because the data was also used for commercial purposes — the FTC has now established that it will require deletion of the commercial data assets built on that foundation. The school official exception is not a passive safe harbor. It is a compliance obligation with real enforcement consequences.

The FERPA/COPPA Intersection: When Both Laws Apply (and Who's In Charge)

Before examining the current state of COPPA's school authorization framework, a correction is necessary: the FTC's 2025 COPPA Rule amendments did not create a new school authorization exception, and they did not codify the existing informal school consent mechanism into Rule text. A substantial number of compliance articles published after April 2025 have stated or implied otherwise. The actual text of the Final Rule tells a different story — one with significant implications for any EdTech product currently structured around school-provided COPPA consent.

What the 2025 COPPA Rule Actually Did (and Didn't Do)

The FTC's April 2025 Final Rule (90 FR 16977, Apr. 22, 2025) made significant amendments to the COPPA Rule — tightening the definition of personal information, adding new parental consent methods, and imposing stricter data security requirements. What it did not do was codify the school authorization exception. In the ed tech section of the preamble, the Commission stated directly: "To avoid making amendments to the COPPA Rule that may conflict with potential amendments to DOE's FERPA regulations, the Commission is not finalizing the proposed amendments to the Rule related to ed tech and the role of schools at this time."

This deferral was not an oversight. The FTC's 2024 Notice of Proposed Rulemaking had specifically proposed codifying new Rule-text definitions of "School" and "School-authorized education purpose" and creating explicit provisions for school-authorized data collection. All of those proposed provisions were dropped from the Final Rule. The Commission committed to monitor the DOE's pending FERPA rulemaking and consider revisiting school authorization after DOE finalizes its amendments.

The Standard That Currently Governs

What governs school COPPA authorization today is the same informal standard that has applied since 2000: FTC guidance contained in the original Rule's Statement of Basis and Purpose and in subsequent FAQ documents, not binding regulatory text. Under that guidance, a school may provide COPPA consent on behalf of parents only when the EdTech operator collects personal information from students "for the use and benefit of the school, and for no other commercial purpose."

The operator must still provide the school with all information required under COPPA — a direct notice describing what personal information will be collected and how it will be used, the opportunity to review and delete the child's information, and the ability to prevent further collection or use. The school's consent substitutes for parental consent only within the educational context. The moment the vendor's data use extends beyond the school's contracted purpose — into product improvement, commercial profiling, or any use that benefits the vendor rather than the school — the school's consent authorization is no longer sufficient, and the vendor must obtain direct parental consent for the additional use.

Why the FTC Deferred: The DOE Rulemaking

The reason the FTC declined to codify school authorization is the Department of Education's pending rulemaking under RIN 1875-AA15. That rulemaking proposes to amend 34 CFR Part 99 — the FERPA implementing regulations — to clarify the rules governing nonconsensual disclosures of student personally identifiable information to third parties, including EdTech vendors specifically. DOE listening sessions in 2022 surfaced significant stakeholder concern about online applications in the classroom collecting student data without adequate parental knowledge or authorization.

Had the FTC codified a school authorization exception in its Rule before DOE finalized 34 CFR Part 99 amendments, the two regulatory regimes could have produced directly conflicting requirements. The FTC's deferral is a deliberate decision to let the FERPA rulemaking set the baseline before locking COPPA Rule text around it. For EdTech counsel, this means the operative compliance question is not "what does the COPPA Rule say about school authorization" — because the Rule says nothing, and the guidance is informal. The operative questions are what the FTC informal guidance requires and what DOE's eventual 34 CFR Part 99 amendments will require, and whether your product's school authorization architecture will survive the transition.

The Dual-Pathway Risk

The scenario that creates the highest FERPA/COPPA intersection risk is a product with two access pathways: a school-licensed version (where the school provisions student accounts and mediates data access) and a direct-to-consumer version (where students or parents create accounts independently). Many EdTech products are built this way — a classroom tool that students can also access from home, or a district-licensed platform with a companion consumer app.

The regulatory implication, confirmed by FTC guidance, is that these two pathways cannot share a single consent architecture. For the school-mediated pathway, school authorization may apply — subject to the "for the use and benefit of the school" limitation. For the direct-to-consumer pathway, there is no school involved, and COPPA requires the operator to obtain verifiable parental consent directly before collecting personal information from children under 13. A product that relies on school authorization to cover both pathways is not in compliance with COPPA, regardless of what its privacy policy says.

The practical design implication is that dual-pathway products need separate data collection flows, separate consent mechanisms, and potentially separate data stores for school-mediated and direct-consumer user sessions. The data a student generates during a school-licensed session is governed by FERPA and the school official exception framework. The data a student generates during a parent-created consumer session is governed by COPPA — with independent parental consent required before any data collection begins. Mixing these data streams into a unified analytics pipeline without separate consent coverage for each is precisely the pattern the FTC targeted in the Edmodo enforcement action.

Edmodo as Enforcement Anchor

Edmodo had school authorization. The platform operated under agreements with school districts, functioned as an LMS, and was nominally within the school official exception framework. What it did not have was clean school authorization for the commercial uses it layered on top of the educational service: behavioral profiling, targeted advertising, and the training of machine learning models on student interaction data. The FTC's position — upheld in the 2023 consent order — was that school authorization is condition-specific. It authorizes data collection for the school's educational purpose. It does not authorize data collection for the vendor's commercial purposes, even when the vendor has a valid school contract for the underlying service.

The consent order required Edmodo to delete models and algorithms developed using personal information collected from children without verifiable parental consent. Not to stop collecting data going forward — to delete the commercial AI assets already built on defectively authorized data. Any EdTech company currently training models on school-provided student data, running analytics pipelines across school and consumer data, or using school-authorized data for any purpose beyond the specific educational service contracted by the school should treat the Edmodo outcome as the roadmap for their own exposure.

Directory Information, Opt-Outs, and the Data Broker Pipeline

Directory information is the category of student data that FERPA allows schools to disclose without prior parental consent. It is also the category most commonly exploited to create data flows that FERPA's drafters never anticipated — and that states like California, New York, and Colorado have moved aggressively to close. Understanding how directory information works, where FERPA's limits end, and where state law takes over is essential for any EdTech vendor that receives student data from schools, whether through a formal contract or through less formal channels.

How Directory Information Works

Under 20 U.S.C. § 1232g(a)(5) and 34 CFR § 99.37, a school may designate certain categories of information as "directory information" — typically name, address, telephone number, email address, date and place of birth, enrollment dates, grade level, participation in activities and sports, and photograph. Before making any directory information disclosure, the school must: (1) give annual public notice to parents of the categories it has designated as directory information; (2) provide a reasonable period of time for parents to opt out, either for all categories or specific ones; and (3) inform parents of their opt-out right. Once that process is complete, the school may disclose designated directory information to third parties without obtaining separate consent for each disclosure.

The opt-out mechanism sounds protective in theory. In practice, opt-out rates at most schools are low, annual notices are buried in student handbooks, and there is no federal requirement that schools verify whether recipients of directory information have a legitimate need for it. FERPA permits the disclosure; it does not restrict what the recipient does with the data after receiving it.

The Re-Disclosure Gap That Creates the Data Broker Pipeline

FERPA's directory information provision contains no re-disclosure restriction. Once a school releases directory information to a third party under 34 CFR § 99.37, the federal statute imposes no limitation on how that third party uses, shares, or monetizes the data. As the American University Law Review has documented, this structural gap means that schools can lawfully share directory information — and, under the school official exception, significantly more sensitive records including grades, disciplinary history, and disability information — with commercial vendors, and those vendors are not federally constrained from reselling or repurposing it.

For EdTech companies, this creates a specific compliance risk that often goes unrecognized: if your product receives directory information from schools and your data practices permit resale, secondary use, or the building of student profiles for non-educational purposes, you may be operating within the technical parameters of FERPA while violating state student privacy statutes that directly regulate vendor conduct. The states did not wait for federal law to close this gap.

California SOPIPA: Vendor-Direct Liability Without a Contract

California's Student Online Personal Information Protection Act, codified at Cal. Ed. Code § 49073.1 et seq., does something FERPA does not: it imposes compliance obligations directly on EdTech operators, at the vendor level, without requiring a formal school contract as a predicate. SOPIPA applies to any website operator, app developer, or online service provider with "actual knowledge" that their service is designed for or primarily used for K-12 educational purposes.

Under SOPIPA, covered operators are prohibited from:

• Selling student information or otherwise disclosing it to third parties for non-educational purposes
• Using student information to engage in targeted advertising, whether on the operator's own platform or elsewhere
• Building commercial profiles of students based on their behavior on the platform
• Using student information in any way that is not related to the educational purpose for which the information was collected

Critically, SOPIPA's coverage is not triggered by whether the school has a formal contract with the operator. An EdTech product that is marketed to teachers, used in classrooms, and known by the operator to be used for K-12 purposes is covered — even if individual teachers downloaded and deployed the tool without a district-level contract. Any EdTech company that has told itself it is outside California's reach because it "only" takes individual teacher signups rather than district licenses needs to revisit that analysis.

New York Education Law § 2-d: Encryption, Seven-Day Notice, $10,000 Penalties

New York's Education Law § 2-d and its implementing regulations at 8 NYCRR Part 121 are the most operationally specific student privacy law in the country for vendor compliance. The statute applies to "third party contractors" — any vendor receiving student data from a New York educational agency under a contract. Its requirements translate directly into technical and contractual controls:

• School contracts must include a Parents' Bill of Rights and specify that PII will be protected and used only for contracted services
• All student PII must be encrypted both in transit and at rest — there is no de minimis exception for small data sets
• Vendors must notify the school of any data breach within seven calendar days — a timeline that requires having incident response procedures that can operate faster than most general commercial breach notification frameworks require
• Vendors are prohibited from selling student PII or using it for advertising
• Civil penalties reach $1,000 for a first violation, $5,000 for a second, and $10,000 for subsequent violations

The seven-day breach notification requirement deserves particular attention for EdTech security planning. Most state breach notification laws allow 30 to 72 hours for notification to regulators — New York requires seven-day vendor-to-school notification, which then triggers the school's own obligations to notify parents and the state. An incident response plan that does not specifically account for the NY Ed Law § 2-d seven-day clock is not adequate for any vendor with New York school customers.

Colorado Title 22: The Subprocessor Flow-Down Requirement

Colorado's Student Data Transparency and Security Act, codified at Colo. Rev. Stat. Title 22, Art. 16 (originally enacted as HB 16-1423), prohibits "School Service Contract Providers" from selling student PII, using it for targeted advertising, building commercial profiles, or disclosing it except for limited purposes. What distinguishes Colorado's law from its California and New York counterparts is an explicit subprocessor flow-down requirement: vendors must impose the same data use restrictions on any subcontractors they use to process student data.

For EdTech companies that rely on third-party infrastructure providers — cloud hosting, analytics platforms, customer success tools, AI/ML providers — the Colorado requirement means that your contractual restrictions on student data use must extend to every downstream processor. A DPA that adequately restricts the EdTech vendor's own conduct but contains no subprocessor flow-down clause is non-compliant under Colorado law.

The Practical Takeaway for DPA Drafting

The combination of the FERPA directory information re-disclosure gap and state-law overlay statutes produces a specific drafting obligation for EdTech Data Processing Agreements: even where federal law technically permits a disclosure, DPAs should contractually prohibit the resale of student data, secondary use for non-contracted purposes, building of commercial profiles, and re-disclosure to any party other than subprocessors bound by equivalent restrictions. These contractual prohibitions are not just best practice — in California, New York, and Colorado, they reflect statutory requirements that apply regardless of what FERPA permits. For EdTech companies operating nationally, the state overlay framework has effectively set the compliance floor higher than FERPA, and DPAs that are written to federal minimum standards are underprotecting both the school and the vendor.

De-Identification Under FERPA and COPPA: Different Standards, Different Risks

De-identification is one of the most commonly invoked — and most frequently misunderstood — concepts in EdTech data compliance. The appeal is obvious: if data is genuinely de-identified, it falls outside both FERPA's definition of an education record and COPPA's definition of personal information, removing both sets of compliance obligations from the analysis. The problem is that both statutes define de-identification differently, neither provides a clear safe harbor, and the re-identification risk in educational data is significantly higher than most EdTech analytics products account for.

FERPA's De-Identification Standard: Reasonableness, Not Checklists

Under 34 CFR § 99.3, data is de-identified when all direct and indirect identifiers have been removed and the releasing agency has made a "reasonable determination" that the student's identity cannot be ascertained from the remaining information. This is a judgment-based, context-specific standard. The regulation does not enumerate a list of fields that must be removed or a specific methodology that, if followed, produces a safe harbor result. The absence of a bright-line procedure is itself a critical compliance fact: EdTech vendors cannot apply a mechanical de-identification process and assume they have satisfied FERPA.

What FERPA's de-identification standard requires is a documented, good-faith analysis of whether the specific data set — in its specific context — retains sufficient information to permit re-identification of individual students. The Department of Education's Student Privacy Policy Office has confirmed that the appropriate de-identification strategy depends on the nature of the data release, the level of protection offered by the specific method, and the usefulness of the resulting data product. A de-identification approach that is adequate for a large urban district's aggregate report may not be adequate for a small rural district's course-level analytics.

COPPA's Approach: Coverage-Based, Not Safe Harbor

COPPA handles de-identification differently. Under 16 CFR § 312.2, COPPA's personal information definition governs what the Rule covers: it includes persistent identifiers, geolocation data, biometric identifiers, photographs and audio/video recordings containing a child's image or voice, and other individually identifiable information. The Rule does not contain an explicit de-identification safe harbor. Its coverage exclusion operates based on whether information is "individually identifiable" — a standard that differs from FERPA's reasonableness-based case-by-case analysis.

The gap between FERPA's reasonableness standard and COPPA's individually-identifiable threshold creates a specific risk for EdTech vendors managing dual-regulated data sets. Data that a vendor has determined is de-identified under FERPA's standard — because the releasing agency has made a reasonable determination that identity cannot be ascertained — may still qualify as individually identifiable information under COPPA's framework if it can be linked to a specific child through persistent identifiers, behavioral signals, or other COPPA-covered categories. For any EdTech product that processes data under both statutes, the conservative compliance posture is to apply whichever standard is more protective for the specific data element or data set.

The Cell-Size Problem in Educational Analytics

The specific re-identification risk that makes de-identification in educational data non-trivial is small group size. NCES statistical standards, which function as best practice guidance (not a formal regulatory safe harbor) for educational data releases, address cell-size suppression directly: many statisticians treat a cell size of 3 as the absolute minimum needed to prevent disclosure, and agencies often require minimum cell sizes of 5 or 10. The Department of Education's FAQ on disclosure avoidance confirms that small cell sizes in aggregated or statistical information from education records may make a student's identity easily traceable, and recommends that agencies suppress all information about small subgroups, combine subgroups to raise the reported count, or apply complementary suppression to prevent reverse calculation.

For EdTech analytics products, this standard creates a specific engineering obligation. A learning analytics dashboard that reports course-level engagement metrics for a class of 30 students — broken down by demographic subgroup, disability status, or English learner status — may be producing reports in which some cells represent 3 to 5 students. Even if no student name or ID number appears in the output, a teacher or administrator reviewing the report may be able to identify specific students from the combination of subgroup membership and behavioral metrics. Building cell-size suppression into reporting pipelines, and documenting the suppression methodology, is not a statistical nicety — it is part of the "reasonable determination" that FERPA's de-identification standard requires.

Re-Identification Risk Beyond Cell Size

Cell size is the most tractable re-identification risk in educational analytics, but it is not the only one. Research on educational data re-identification has documented that the combination of a student's unique course schedule, disability status, and school enrollment year can create a quasi-unique fingerprint even in datasets where no direct identifiers appear. A dataset reporting that a student at a specific school is enrolled in AP Chemistry, receives special education services, and participates in the robotics club may identify that student with certainty in a school of 200, even though no name, ID, or date of birth appears anywhere in the record.

NCES technical briefs on data de-identification address this problem directly, noting that individual-level data released with record codes — codes intended to allow researchers to track student performance across time — can create a re-identification vector if the code can be linked back to identifying information held by the school. EdTech products that generate persistent student identifiers, even pseudonymous ones, need to assess whether those identifiers can be reverse-linked to identity through the school's own records.

The Re-Identification Prohibition Clause

The most actionable de-identification compliance step that the SPPO has endorsed is contractual: when de-identified data will be transferred to any party — including subprocessors, analytics partners, or research collaborators — the agreement should contractually prohibit the recipient from attempting to re-identify any student in the data. This prohibition does not create a regulatory safe harbor under FERPA, but it is a material factor in the "reasonable determination" analysis. It also provides a contractual basis for terminating the relationship and potentially pursuing the recipient if re-identification is attempted.

EdTech vendors should include re-identification prohibition language in three places: the school-facing DPA, any subprocessor agreements for parties who access student data, and internal data governance policies governing how employees and contractors interact with de-identified datasets. A prohibition in the DPA that is not reflected in subprocessor agreements creates a gap — the school has the vendor's promise, but the vendor has not bound its downstream processors to the same standard. Both California's SOPIPA and Colorado's student data statute require subprocessors to be bound by equivalent restrictions, meaning the re-identification prohibition clause is not just good practice; it is required under state law for vendors operating in those markets.

The 2025 FERPA Deferral: What Happened and What It Means for EdTech

A specific misconception has circulated in EdTech compliance circles since the FTC's April 2025 COPPA Rule amendments were published: that the 2025 Rule codified the school authorization exception for COPPA consent, creating a new statutory basis for schools to provide COPPA consent on behalf of parents. This is not what happened. Understanding what the 2025 Rule actually did — and explicitly declined to do — is essential for any EdTech company that has updated its compliance architecture based on coverage of the rule amendments.

What the 2024 NPRM Proposed

The FTC's 2024 Notice of Proposed Rulemaking proposed several significant changes to the COPPA Rule's treatment of EdTech and schools. The NPRM proposed creating new defined terms — "School" and "School-authorized education purpose" — and adding Rule-text provisions that would have codified the circumstances under which schools could provide COPPA consent on behalf of parents. These proposed provisions would have transformed the existing informal guidance standard (anchored in a 2000 Statement of Basis and Purpose and subsequent FAQ documents) into binding regulatory text with the legal status that comes from notice-and-comment rulemaking. For EdTech vendors, codification would have provided a more stable compliance foundation than reliance on guidance documents alone.

EdTech companies that reviewed the 2024 NPRM and began structuring consent architectures around the proposed school authorization framework need to know: those provisions were not finalized.

The 2025 Final Rule: An Explicit Deferral

The Final Rule published at 90 FR 16977 (Apr. 22, 2025) dropped all proposed EdTech and school authorization provisions. In the preamble's ed tech section, the Commission explained its reasoning in direct terms: "To avoid making amendments to the COPPA Rule that may conflict with potential amendments to DOE's FERPA regulations, the Commission is not finalizing the proposed amendments to the Rule related to ed tech and the role of schools at this time."

The FTC further committed to monitoring the DOE's regulatory developments and revisiting the school authorization question after DOE finalizes its FERPA amendments: the Commission "will continue to monitor and weigh future developments with respect to DOE's potential FERPA regulation amendments in deciding whether to pursue COPPA Rule amendments related to ed tech."

This language establishes two key facts. First, the current state of school authorization under COPPA is informal guidance only — the same guidance-document standard that has applied since 2000, now explicitly confirmed by the agency as the operative standard pending further rulemaking. Second, the FTC has signaled that it intends to revisit school authorization once the FERPA framework is updated, which means the compliance architecture applicable to EdTech school authorization is explicitly in flux.

The Pending Rulemaking: RIN 1875-AA15

The event that triggered the FTC's deferral is the Department of Education's pending rulemaking tracked as RIN 1875-AA15. The DOE is developing amendments to 34 CFR Part 99 — the FERPA implementing regulations — specifically to clarify the rules governing nonconsensual disclosures of student personally identifiable information to third parties, including EdTech vendors. The rulemaking was informed by DOE listening sessions held in February 2022, at which stakeholders raised concerns about online applications collecting student data in classrooms without adequate parental knowledge or authorization.

As of April 2025, no NPRM under RIN 1875-AA15 had been published and no final rule had issued. The rulemaking is on the DOE's unified regulatory agenda, but no legal deadline exists for finalization. EdTech counsel monitoring this area should track the DOE's regulatory agenda for any NPRM publication — because when DOE finalizes 34 CFR Part 99 amendments, the FTC has committed to reassessing whether to codify COPPA school authorization provisions that align with the new FERPA framework. That assessment will produce additional rulemaking, and EdTech products structured around the current informal guidance may need to restructure their consent architecture to comply with whatever emerges.

What This Means for EdTech Products Today

The practical compliance implications of the deferral are concrete. EdTech vendors currently relying on school authorization as the sole consent mechanism for COPPA purposes are relying on guidance documents, not Rule text. Guidance documents can be withdrawn, modified, or superseded without notice-and-comment rulemaking. The FTC's informal guidance that schools may provide COPPA consent "for the use and benefit of the school, and for no other commercial purpose" remains operative — but it is not the stable regulatory foundation that codified Rule text would provide.

Privacy advocates, including the Public Interest Privacy Center, have criticized the FTC's deferral reasoning, arguing that the FTC — which regulates EdTech vendors directly — should not defer child privacy protections pending DOE's rulemaking timeline. They note that schools have been seeking codified COPPA school authorization guidance since before the DOE's own Inspector General mandated a FERPA rulemaking in 2018. Whether or not that criticism persuades the FTC, it reflects the advocacy environment surrounding EdTech data practices — an environment in which informal guidance may be challenged, tested, or re-interpreted through enforcement actions.

The strategic compliance response is not to abandon school authorization as a mechanism — for many EdTech products, it is both practical and appropriate. The strategic response is to treat school authorization as a supplemental mechanism rather than a sole-reliance strategy. Products that can structure their data flows to obtain independent parental consent for at least the most sensitive data uses have a more defensible compliance posture than products built entirely around school-provided authorization. The more a product's COPPA compliance depends on school authorization, and the more commercially valuable the uses made of school-authorized data, the greater the exposure if the informal guidance standard is tightened — whether through rulemaking or through enforcement.

Monitoring the Regulatory Timeline

For EdTech legal teams, the two regulatory events to track are: (1) any NPRM published under DOE RIN 1875-AA15 at regulations.gov, which will signal that the FERPA amendment process is moving toward finalization; and (2) any FTC supplemental rulemaking notice regarding COPPA school authorization provisions, which the 2025 Final Rule preamble signals will follow DOE's FERPA rulemaking. The comment periods on both rulemakings will present opportunities to shape the final rules, and the interim period — before either rulemaking finalizes — is the window in which products built on informal guidance are most exposed if enforcement actions test the boundaries of the current standard.

FERPA Compliance Checklist for EdTech Vendors

The legal framework covered in the preceding sections translates into a specific set of operational and contractual requirements for any EdTech vendor that receives student data from schools. The checklist below maps each requirement to its legal authority. Treat this as a baseline — state law requirements in California, New York, and Colorado impose additional obligations beyond this federal floor.

1. School Official DPA Provisions — 34 CFR § 99.31(a)(1)

Every school agreement under which your product receives student education records must expressly establish that your company qualifies as a school official by: (a) identifying the specific institutional service or function you perform that the school would otherwise perform with employees; (b) confirming that the school exercises direct control over your use and maintenance of education records; and (c) making you subject to the use and redisclosure limitations of 34 CFR § 99.33(a). Generic data processing terms that do not address these elements are not compliant school official agreements.

2. Data Use Limitation Clause — 34 CFR § 99.33(a)

Your DPA must contractually prohibit using education records for any purpose other than the specific educational service contracted by the school. This means explicitly excluding: product improvement using school-provided data, training AI or machine learning models on education records, building commercial profiles of students, generating aggregate analytics sold to third parties, and any use that benefits the vendor rather than the contracted school function. A data use limitation clause that contains only general "educational purposes" language without these specific exclusions is inadequate.

3. Directory Information Handling — 34 CFR § 99.37

If your product receives or processes directory information, your DPA should specify that (a) the school has completed the required annual notice and opt-out process before any directory information is disclosed, and (b) your company prohibits re-disclosure of directory information to third parties except to subprocessors bound by equivalent restrictions. Federal law does not require this contractual prohibition — but California SOPIPA, New York Education Law § 2-d, and Colorado Title 22 effectively do, and building it into your standard DPA eliminates the need for state-specific contract riders.

4. De-Identification Methodology Documentation — NCES Standards

If your product generates de-identified reports or releases de-identified data to any party, document your de-identification methodology in writing and maintain that documentation. The methodology should address: minimum cell-size thresholds for any subgroup reporting (5 is a common baseline; 10 provides stronger protection); complementary suppression for cells that could be reverse-calculated from other reported values; and a process for periodic re-assessment as your user base or data set changes. NCES statistical standards provide a best practice framework, but note that NCES guidance is advisory, not a regulatory safe harbor — your documentation should demonstrate a good-faith reasonableness analysis under 34 CFR § 99.3, not just compliance with a checklist.

5. COPPA/FERPA Dual-Path UX for Mixed-Access Products — FTC Informal Guidance

If your product is accessible both through school provisioning (where the school mediates student access) and through direct parent or student sign-up (where there is no school intermediary), implement separate data collection flows for each pathway. School-mediated access may use school authorization under current FTC informal guidance — provided data collection is limited to educational purposes with no commercial use. Direct consumer access by children under 13 requires independent verifiable parental consent before any personal information is collected. Do not rely on school authorization to cover both pathways, and do not co-mingle data collected under each pathway in shared analytics pipelines without separate consent coverage.

6. School Authorization Scope Limitation — FTC Informal Guidance (Not Rule Text)

Where your product relies on school authorization as the COPPA consent mechanism, the written school agreement must confirm that your data collection is "for the use and benefit of the school, and for no other commercial purpose." This is a guidance-document standard — currently the operative standard under the FTC's 2025 deferral of COPPA school authorization codification — and it should be reflected in your DPA language, not just assumed. Schools should be provided with a specific description of all personal information your product collects, how it is used, and the opportunity to review and delete student information on request.

7. Data Retention Policy — Edmodo Order Benchmark (One Year)

The 2023 FTC consent order against Edmodo required a one-year maximum data retention limit for student personal information. This represents the FTC's current enforcement benchmark for EdTech data retention. Your data governance policy should specify retention periods for each category of student data your product processes, with a default maximum aligned to the Edmodo benchmark for data received under school official authority. Retention periods for de-identified analytics data may be longer, but must account for re-identification risk as the retained dataset grows.

8. Subprocessor Flow-Down Clause

Your DPA must require that any subprocessor receiving student data from you is bound by data use restrictions equivalent to those in your school agreement. This is not only a best practice — it is required under Colorado's Colo. Rev. Stat. Title 22, Art. 16 and, in effect, under California's SOPIPA for California-resident students. The flow-down clause should: identify categories of subprocessors authorized to receive student data; prohibit subprocessors from using student data for commercial purposes; require subprocessors to implement security controls at least as protective as yours; and give you the contractual right to audit or certify subprocessor compliance.

9. Student and Parent Access Rights Mechanism

Schools retain their FERPA obligations to provide parents and eligible students with access to education records, the right to request corrections, and the right to consent to or withhold disclosure. When your product maintains education records, your DPA should address how you will support the school in responding to parent and student access requests — including providing a mechanism for the school to export, review, or delete a specific student's data on request. Build this capability into your product architecture before a school requests it, not after.

10. Incident Response Notification — NY Ed Law § 2-d Seven-Day Standard

If your product has any New York school customers, your incident response plan must include a process for notifying the school of any data breach within seven calendar days — the requirement under New York Education Law § 2-d and 8 NYCRR Part 121. Seven days is significantly shorter than most general state breach notification frameworks (which typically allow 30 to 72 hours for regulator notification, not school notification). Map your incident detection, escalation, and notification workflows against this timeline to confirm you can meet it. For practical purposes, the NY Ed Law § 2-d seven-day clock is the highest-urgency student data breach notification standard in the country and should be treated as the default standard for all school breach notifications, even in states without an equivalent requirement.

State Overlay Table

The following state laws impose vendor-direct obligations that exceed the FERPA federal floor. Any EdTech product serving schools in these states must layer these requirements on top of FERPA baseline compliance:

• California — SOPIPA (Cal. Ed. Code § 49073.1 et seq.): Applies to operators with actual knowledge their service is used for K-12 purposes, without requiring a formal school contract. Prohibits sale, targeted advertising, and commercial profiling. No contract required to trigger coverage.
• New York — Education Law § 2-d and 8 NYCRR Part 121: Requires encryption in transit and at rest, Parents' Bill of Rights in school contracts, seven-day breach notification, and prohibits sale and advertising use. Civil penalties up to $10,000 per subsequent violation.
• Colorado — Colo. Rev. Stat. Title 22, Art. 16 (HB 16-1423): Prohibits sale, targeted advertising, and commercial profiling. Requires subprocessor flow-down. Applies to "School Service Contract Providers."

Vendors operating across multiple states face a patchwork of state requirements that in most cases exceed FERPA minimums. DPAs drafted to the highest applicable state standard — which for most national EdTech providers means NY Ed Law § 2-d's encryption and breach notification requirements combined with SOPIPA's vendor-direct liability structure — will generally satisfy the federal floor as well and reduce the need for state-specific contract variations.

Promise Legal helps EdTech companies build FERPA- and COPPA-compliant data practices before enforcement targets them. Contact us to audit your school agreements.