FERPA Compliance for EdTech Companies: The Complete Guide to Student Privacy and Winning School District Contracts

The K-12 education technology market in the United States is worth $185 billion annually. School districts across the country are purchasing learning management systems, assessment platforms, student information systems, AI tutoring tools, and hundreds of other EdTech products. The buyers are sophisticated, the contracts are large, and the procurement requirements are strict.

At the center of every EdTech procurement decision sits a single federal law: FERPA -- the Family Educational Rights and Privacy Act. If your company builds, sells, or operates technology that touches student data, FERPA compliance is not optional. It is the baseline requirement that determines whether a school district will evaluate your product, sign your contract, or even take your first sales call.

And yet, FERPA compliance remains one of the most misunderstood requirements in the technology industry. There is no "FERPA certification" to obtain. There is no audit report to hand over. FERPA compliance is demonstrated through a combination of policies, technical controls, contractual commitments, and operational practices -- and school districts have become increasingly rigorous about verifying that vendors actually meet these standards before approving them.

This guide covers everything EdTech companies and education vendors need to know about FERPA compliance in 2026: what the law requires, who must comply, what counts as an education record, how to handle the vendor relationship with schools, what technical safeguards you need, how FERPA interacts with COPPA and state privacy laws, and how to turn FERPA compliance into a competitive advantage that wins school district contracts.

What Is FERPA? (Family Educational Rights and Privacy Act)

FERPA -- the Family Educational Rights and Privacy Act -- is a federal law enacted in 1974 that protects the privacy of student education records. Originally sponsored by Senator James Buckley, FERPA is sometimes referred to as the Buckley Amendment. It is codified at 20 U.S.C. Section 1232g, with implementing regulations at 34 CFR Part 99.

The core purpose of FERPA

FERPA was designed to accomplish two objectives:

Give parents rights over their children's education records. Parents have the right to inspect and review their child's education records, request corrections to records they believe are inaccurate, and control the disclosure of personally identifiable information (PII) from those records to third parties.
Restrict unauthorized disclosure of student information. Educational institutions that receive federal funding are prohibited from disclosing PII from education records without the prior written consent of the parent (or the eligible student, once the student turns 18 or enrolls in a postsecondary institution).

A brief history of FERPA

FERPA was enacted in 1974, well before the internet, cloud computing, or educational technology existed in any recognizable form. The original law was designed to address a narrow problem: schools sharing student records with third parties -- employers, government agencies, other institutions -- without parental knowledge or consent.

Over the following five decades, FERPA has been amended multiple times to address evolving threats to student privacy. The most significant amendments for EdTech companies include:

2008 amendments clarified the "school official" exception (more on this below), which is the legal mechanism that allows schools to share student data with technology vendors without obtaining individual parental consent.
2011 regulatory updates from the Department of Education further defined how the school official exception applies to outside service providers, explicitly addressing the role of technology vendors and contractors.
2012 and subsequent guidance from the Student Privacy Policy Office (SPPO) within the Department of Education addressed cloud computing, online educational services, and the specific obligations of EdTech vendors operating under the school official exception.

Despite being more than 50 years old, FERPA remains the foundational federal law governing student privacy. It has been supplemented -- but not replaced -- by newer laws like COPPA and a wave of state student privacy legislation that began in 2014.

Who does FERPA protect?

FERPA protects the education records of all students who attend educational institutions that receive funding under any program administered by the U.S. Department of Education. In practice, this includes:

Students at public K-12 schools (virtually all of which receive federal funding)
Students at public and private postsecondary institutions that accept federal financial aid
Students at many private K-12 schools that participate in federal programs

The rights under FERPA belong to the parent until the student turns 18 or enrolls in a postsecondary institution, at which point the rights transfer to the student (who becomes an "eligible student" under the law).

Who Must Comply with FERPA?

This is where many EdTech companies make their first mistake. They assume FERPA applies only to schools. It does not.

Direct obligation: educational institutions

FERPA's direct legal obligation falls on educational institutions -- specifically, any educational agency or institution that receives funds under any program administered by the U.S. Department of Education. The penalty for non-compliance is severe: the Department of Education can withdraw all federal funding from the institution. For a public school district, this means losing Title I funding, IDEA funding, free and reduced lunch program funding, and every other federal education program dollar. No school district will risk this.

Indirect obligation: EdTech vendors and service providers

Here is the critical point for technology companies: while FERPA does not directly regulate vendors, it creates obligations that schools impose on their vendors through contracts.

When a school shares student education records with a technology vendor, the school is making a disclosure under FERPA. That disclosure must fall within one of FERPA's permitted exceptions to the consent requirement. The most common exception used for EdTech vendors is the school official exception (34 CFR Section 99.31(a)(1)(i)(B)), which allows schools to share education records with outside parties that the school has determined perform an institutional service or function.

For this exception to apply, the vendor must be under the direct control of the school with respect to the use and maintenance of education records. In practice, this means the school and the vendor must have a contractual agreement that specifies:

The vendor performs an institutional service or function for which the school would otherwise use employees
The vendor is under the direct control of the school regarding use and maintenance of education records
The vendor uses education records only for the purposes specified in the agreement
The vendor meets the criteria specified in the school's annual FERPA notification to parents

If you are an EdTech vendor, FERPA compliance is not something you do independently -- it is something you do in partnership with the school districts you serve. Your contractual obligations, your technical controls, and your data handling practices all must satisfy the school's requirements under FERPA.

The practical implication for EdTech companies

Every school district procurement team, every district CTO, and every district legal counsel will evaluate your FERPA compliance posture before approving your product. This evaluation is not discretionary -- it is a legal necessity for the district. If a district allows a vendor to access student data without appropriate contractual controls, the district itself is in violation of FERPA.

This is why FERPA compliance is the single most important factor in EdTech sales. Not because the federal government is going to fine you directly, but because no school district will sign a contract with a vendor that cannot demonstrate FERPA compliance.

What Are Education Records Under FERPA?

FERPA's protections apply specifically to "education records." Understanding what does and does not qualify as an education record is essential for EdTech companies designing data handling policies.

Definition of education records

Under FERPA, education records are defined as records that are:

Directly related to a student, AND
Maintained by an educational agency or institution, or by a party acting for the agency or institution

The second element is critical for EdTech vendors. When your platform stores student data on behalf of a school, that data is being maintained "by a party acting for the agency or institution." It is an education record, and FERPA applies.

What is included in education records

Education records encompass a broad range of information. For EdTech companies, the following data types commonly qualify:

Student names and identification numbers (including district-assigned IDs)
Grades, test scores, and assessment results
Attendance records
Class schedules and course enrollment information
Special education records and IEP documents
Behavioral and disciplinary records
Student work products (essays, assignments, projects submitted through the platform)
Learning analytics data (time-on-task metrics, error patterns, performance trends, engagement scores)
AI-generated assessments and recommendations about a student's academic performance or needs
Parent or guardian contact information when linked to a student record
Demographic data (race, ethnicity, gender, date of birth, address)
Free and reduced lunch eligibility status
Health records maintained by the school (distinct from records maintained by a school nurse or physician in certain circumstances)

What is excluded from education records

Certain categories of records are explicitly excluded from FERPA's definition of education records:

Sole possession records -- notes made by a school official that remain in the sole possession of the maker and are not shared with anyone else (e.g., a teacher's personal notes)
Law enforcement unit records maintained by a school's law enforcement unit
Employment records (when the student is employed by the school and the records relate solely to the employment)
Records maintained by a physician, psychologist, or other recognized professional that are used only for treatment and disclosed only to individuals providing treatment
Records that contain only information about an individual after they are no longer a student at the institution (alumni records created after attendance)

De-identified data and FERPA

FERPA permits the disclosure of de-identified data -- that is, data from which all personally identifiable information has been removed -- without consent. However, the standard for de-identification under FERPA is strict: the educational agency or institution must make a reasonable determination that the student's identity is not personally identifiable, whether through single or multiple releases, taking into account other reasonably available information.

For EdTech companies building analytics, benchmarking, or research features, this matters. Aggregated or de-identified data may fall outside FERPA's consent requirements, but only if the de-identification is robust enough to prevent re-identification. Given advances in re-identification techniques, the bar for what constitutes adequate de-identification continues to rise.

FERPA Requirements for EdTech Companies and Vendors

If your company processes student data on behalf of a school, your FERPA obligations flow from the school official exception and the contractual terms the school imposes. Here are the specific requirements EdTech companies must satisfy.

The school official exception: how it works

The school official exception (34 CFR Section 99.31(a)(1)) is the legal foundation for almost every EdTech vendor relationship. Under this exception, a school can disclose education records to a vendor without parental consent if:

The vendor performs an institutional service or function that the school would otherwise use its own employees to perform
The vendor has been determined to meet the criteria set forth in the school's annual FERPA notification as a "school official" with a "legitimate educational interest"
The vendor is under the direct control of the school with respect to the use and maintenance of education records
The vendor uses education records only for the purposes for which the disclosure was made

What "direct control" means in practice: The school must have a written agreement with the vendor that governs how the vendor uses, maintains, and protects education records. The agreement must be specific enough that the school can enforce its terms. This is why school districts require formal data sharing agreements, data privacy agreements, or terms of service that explicitly address FERPA requirements.

Directory information

FERPA allows schools to designate certain categories of student information as "directory information" -- information that the school may disclose without prior consent. Common directory information categories include:

Student name
Address
Telephone number
Date and place of birth
Grade level
Participation in officially recognized activities and sports
Dates of attendance

However, parents have the right to opt out of directory information disclosures, and schools must provide annual notice of what they classify as directory information. EdTech vendors should not assume that any student data they receive is "directory information" unless the school explicitly confirms it and has provided the required opt-out opportunity.

Outside of the school official exception and a limited number of other exceptions (e.g., health or safety emergencies, judicial orders, state and local education authorities conducting audits), FERPA requires prior written consent from the parent (or eligible student) before disclosing PII from education records. The consent must:

Specify the records that may be disclosed
State the purpose of the disclosure
Identify the party or class of parties to whom the disclosure may be made
Be signed and dated by the parent or eligible student

For EdTech companies, the practical takeaway is this: if your use of student data falls outside the scope of the school official exception or another FERPA exception, you need individual parental consent. This is particularly relevant if you want to use student data for purposes beyond the educational services you provide to the school -- such as product development, advertising, research, or sale to third parties.

Restrictions on re-disclosure

When a vendor receives education records under the school official exception, the vendor may not re-disclose that information to other parties unless the re-disclosure itself falls within a FERPA exception. This means:

You cannot share student data with subcontractors unless they are also operating under an appropriate exception (and the school's agreement authorizes the subcontracting)
You cannot use student data for marketing, advertising, or creating marketing profiles
You cannot sell student data to third parties
You cannot share student data with affiliated companies for purposes beyond the educational service

These restrictions must be reflected in your architecture, your data flows, your vendor agreements, and your internal access controls.

FERPA vs COPPA: How Both Apply to K-12 EdTech

One of the most common sources of confusion for EdTech companies is the relationship between FERPA and COPPA (the Children's Online Privacy Protection Act). Both laws protect children. Both impose obligations on companies that collect children's data. But they operate through fundamentally different mechanisms.

What COPPA requires

COPPA, enforced by the Federal Trade Commission (FTC), applies to operators of websites, online services, and apps that are directed to children under 13 or that have actual knowledge that they are collecting personal information from children under 13. COPPA requires operators to:

Post a comprehensive privacy policy describing data practices
Provide direct notice to parents about data collection
Obtain verifiable parental consent before collecting personal information from children under 13
Give parents the ability to review, delete, and refuse further collection of their child's data
Implement reasonable security measures to protect children's data
Limit data collection to what is reasonably necessary for the child's participation in the activity

When COPPA applies to EdTech

If your EdTech product is directed at children under 13 (which includes virtually all K-5 products and many K-8 products), or if you have actual knowledge that users are under 13, COPPA applies. This is true regardless of whether the product is used in a school setting.

Here is where FERPA and COPPA intersect in a way that is crucial for EdTech companies. The FTC has acknowledged that schools can provide consent on behalf of parents for the collection of children's personal information, but only when the collection is for educational purposes and not for commercial purposes.

This is known as the "school consent" mechanism, and it works as follows:

The school (not the vendor) determines that the EdTech product serves an educational purpose
The school provides consent on behalf of parents for the collection of student data for that educational purpose
The vendor must not use the data for any commercial purpose unrelated to the educational service
The vendor must not condition a child's participation on the collection of more data than is reasonably necessary

What this means in practice: For K-12 EdTech products used under 13, you typically need both FERPA and COPPA compliance. FERPA governs the disclosure of education records from the school to you. COPPA governs your collection of personal information from children under 13. The school consent mechanism allows the school to provide COPPA consent on behalf of parents, but only for educational uses -- which conveniently aligns with the restrictions already imposed by the FERPA school official exception.

The overlap is not perfect. Key differences include:

Requirement	FERPA	COPPA
Who it regulates	Educational institutions receiving federal funding	Operators of online services directed to children under 13
Enforcement	Department of Education (can withdraw federal funding)	FTC (civil penalties up to $50,120 per violation)
Consent mechanism	School official exception eliminates need for individual consent	School can provide consent for educational purposes only
Data use restriction	Must be for purposes specified in the school agreement	Must be for educational purposes; no commercial use
Age threshold	No age limit -- applies to all students at covered institutions	Under 13 only
Applies to vendors?	Indirectly, through school contracts	Directly, if the service is directed to children under 13

For a comprehensive look at how an EdTech startup navigated the intersection of SOC 2, FERPA, and COPPA in a real procurement cycle, see our EdTech case study: SOC 2 and student privacy compliance in 7 weeks.

School districts do not take your word for FERPA compliance. They require formal, written agreements that establish your obligations as a recipient of student education records. These agreements take several forms, and large districts often require more than one.

The Student Data Privacy Agreement (SDPA / National DPA)

The Student Data Privacy Consortium (SDPC) -- a collaborative of schools, districts, state agencies, and education organizations -- developed the National Data Privacy Agreement (National DPA), which has become the de facto standard for EdTech vendor agreements across the United States. As of 2026, more than 4,000 school districts and 28 state education agencies use the SDPC framework.

The National DPA covers:

Data collection scope -- what student data the vendor will receive, and the legal basis for each category
Purpose limitation -- the specific educational purposes for which data may be used
Data security obligations -- minimum security standards the vendor must maintain
Breach notification -- timelines and procedures for notifying the school of a data breach (often 24-72 hours, more aggressive than many state breach notification laws)
Data deletion -- requirements to delete or return student data upon contract termination or school request
Prohibition on data sale -- explicit prohibition on selling, renting, or leasing student data
Prohibition on advertising -- prohibition on using student data for targeted advertising
Subcontractor requirements -- obligations for ensuring subprocessors meet the same standards
Transparency -- requirements for disclosing what data is collected, how it is used, and who has access
Parent and student rights -- mechanisms for parents to access, review, and request deletion of their child's data

State-specific data privacy agreements

Many states have developed their own student data privacy agreement frameworks, often with requirements that exceed the National DPA. For example:

California requires compliance with AB 1584 (the California Student Online Personal Information Protection Act -- often confused with SOPIPA, which is a separate law)
New York requires a Parents' Bill of Rights for Data Privacy and Security under Education Law 2-d
Colorado requires compliance with HB 16-1423 and the Student Data Transparency and Security Act

EdTech vendors selling across multiple states frequently need to sign a National DPA at the national level plus state-specific addenda.

What to expect in the agreement process

School districts typically require the following from vendors before contract execution:

Completion of the SDPC vendor application -- a detailed questionnaire about your data practices, security controls, and privacy policies
Review and signature of the National DPA (or a district-specific agreement based on the National DPA template)
A privacy policy that specifically addresses student data and meets the transparency requirements in the agreement
Evidence of security controls -- this may range from a simple questionnaire response to a formal request for a SOC 2 Type II report, depending on the district's size and sophistication
Data inventory -- a complete listing of all student data elements your product collects, processes, and stores

Preparing these materials in advance -- rather than scrambling when a district sends the request -- is what separates EdTech vendors who close deals on schedule from those who lose them to competitors who came prepared.

FERPA Technical Requirements: Securing Student Data

FERPA itself does not prescribe specific technical standards the way HIPAA's Security Rule does. The law requires "reasonable methods" to protect education records and restrict access to authorized parties. However, the contractual obligations imposed by school districts through data sharing agreements -- combined with FTC enforcement expectations under COPPA and industry best practices -- create a clear set of technical requirements for EdTech vendors.

Encryption

Data in transit: All student data must be encrypted during transmission using TLS 1.2 or higher. This includes API communications, web traffic, data imports/exports, and any other data exchange between your platform and the school's systems.
Data at rest: Student data stored in databases, file systems, backups, and logs must be encrypted using AES-256 or equivalent. This includes production databases, analytics data stores, and development/staging environments that contain real student data (which should be avoided -- see data minimization below).

Access controls

Role-based access control (RBAC): Implement granular access controls that restrict access to student data based on role. Not every employee needs access to student records. Engineers maintaining the database infrastructure need different access than customer support staff, who need different access than the school's designated administrators.
Multi-factor authentication (MFA): Require MFA for all internal access to systems that store or process student data. This includes production infrastructure, administrative dashboards, and database consoles.
Least privilege: Grant the minimum level of access necessary for each role. Review and revoke access when roles change or employees depart.
School-side access controls: Provide school administrators with the ability to control which staff members within their district can access student data through your platform. Teachers should see only their own students' data. Principals should see only their school's data. District administrators may need cross-school access.

Audit logging

Log all access to student data. Every read, write, update, and delete operation on student records should be logged with the identity of the user, the timestamp, the data accessed, and the action performed.
Log retention. Retain audit logs for a minimum of one year (many districts require longer). Logs must be tamper-resistant -- stored in a way that prevents modification or deletion.
Log review. Establish a process for periodic review of access logs. Anomalous access patterns -- such as a user accessing an unusually large number of records, or access from an unexpected location -- should trigger investigation.

Data minimization

Collect only what you need. Do not collect student data elements that your product does not require for its educational purpose. If your platform does not need student home addresses, do not collect them. Every additional data element increases your risk exposure and your obligations under FERPA.
Retention limits. Do not retain student data indefinitely. Establish retention schedules aligned with the educational purpose and the school's data sharing agreement. When data is no longer needed, delete it.
No real data in non-production environments. Development, staging, and testing environments should use synthetic or anonymized data. Real student records should never be copied to non-production systems.

Data deletion and portability

Contractual deletion obligations. Your platform must be able to delete all student data associated with a school district upon request or upon termination of the contract. This is a standard requirement in every SDPC National DPA and most district agreements.
Timely deletion. Districts typically require deletion within 30-60 days of a request. Your systems must be architecturally capable of meeting this timeline.
Deletion verification. Be prepared to provide certification that data has been deleted, including from backups. Some districts require written confirmation that no copies of student data remain in any system, backup, or archive.

Incident response and breach notification

Incident response plan. Maintain a documented incident response plan that specifically addresses breaches involving student data. The plan should include identification, containment, eradication, recovery, notification, and post-incident review procedures.
Breach notification timelines. Most data sharing agreements require notification within 24-72 hours of discovering a breach involving student data. This is significantly faster than many state breach notification laws, which typically allow 30-60 days. Your incident response process must be capable of meeting the contractual timeline.

For a detailed guide on building an incident response plan that meets compliance requirements across frameworks, see our incident response plan guide.

FERPA and State Student Privacy Laws

FERPA establishes the federal floor for student privacy, but states have built significantly higher ceilings. Since 2014, a wave of state student privacy legislation has created a patchwork of additional requirements that EdTech companies must navigate. As of 2026, more than 40 states have enacted student privacy laws that go beyond FERPA.

California: SOPIPA and AB 1584

California leads the nation in student privacy legislation:

SOPIPA (Student Online Personal Information Protection Act, SB 1177) prohibits operators of websites, online services, and apps designed and marketed for K-12 purposes from: selling student data, using student data for targeted advertising, creating advertising profiles of students, and using student data for any purpose other than the educational purpose for which the data was disclosed. SOPIPA applies directly to vendors -- unlike FERPA, it does not depend on the school's contractual requirements.
AB 1584 amends the California Education Code to require school districts that enter into contracts with third-party vendors to include specific provisions addressing student data privacy, security, and deletion.

New York: Education Law 2-d

New York's Education Law 2-d is one of the most comprehensive state student privacy laws in the country. It requires:

A Parents' Bill of Rights for Data Privacy and Security that must be published by every educational agency and every third-party contractor that receives student data
Data security and privacy plans from every vendor that receives student data
Breach notification within timeframes specified by the state (currently, without unreasonable delay)
Civil penalties for unauthorized disclosure of student data -- up to $150,000 per violation
Compliance with the NIST Cybersecurity Framework as the baseline security standard

Colorado: Student Data Transparency and Security Act

Colorado's law (HB 16-1423) requires:

Public disclosure of the types of student data collected and the purposes for collection
Written consent before using student data for purposes other than those specified in the school contract
Data deletion upon request or contract termination
Annual notification to schools of any data security breaches

Other notable state laws

Connecticut (PA 16-189): Prohibits targeted advertising using student data, requires data deletion upon request, and mandates security audits.
Illinois (SOPPA -- Student Online Personal Protection Act): Requires a detailed data inventory, prohibits targeted advertising, and requires a breach notification procedure. The Illinois SOPPA also requires vendors to provide a list of all sub-processors who will have access to student data.
Virginia (SDPA -- Student Data Privacy Act): Establishes requirements for data governance plans, breach notification, and vendor transparency.
Maryland, Georgia, Louisiana, and others have enacted laws with varying levels of specificity regarding vendor obligations, data minimization, breach notification, and advertising restrictions.

The practical impact for EdTech vendors

If you sell to school districts in multiple states, you are subject to the most restrictive applicable law for each district. This creates a strong incentive to build your data practices to the highest standard from the start rather than attempting to maintain different policies for different states. A single, rigorous data governance framework that meets the requirements of California, New York, Illinois, and Colorado will satisfy every other state's requirements as well.

FERPA Compliance Checklist for EdTech Companies

Use this checklist as a practical guide for assessing and demonstrating your FERPA compliance posture. Each item represents a requirement that school districts commonly evaluate during procurement.

Policies and documentation

Student data privacy policy -- A public-facing policy that describes what student data you collect, why you collect it, how you use it, who has access, and how you protect it. This must be written in plain language and accessible to parents.
Data governance policy -- An internal policy governing how student data is classified, stored, accessed, retained, and deleted.
Incident response plan -- A documented plan for responding to data breaches involving student data, including notification timelines that meet the most aggressive contractual and state requirements.
Employee training program -- Documented training for all employees who may access student data, covering FERPA requirements, COPPA requirements, and your company's data handling policies.
Subprocessor management policy -- A policy and process for evaluating and monitoring subcontractors who may access student data.

Contractual readiness

SDPC National DPA signed (or readiness to sign) -- If you have not signed the National DPA, prepare by reviewing the template, identifying any gaps in your practices, and resolving them before the first district asks.
Standard terms of service that address FERPA -- Your standard terms should include provisions for data use limitations, data deletion, breach notification, and compliance with applicable student privacy laws.
State-specific addenda -- Prepare addenda for states with specific requirements (California, New York, Illinois, Colorado at a minimum).
Data processing agreement template -- A template that can be adapted for districts with custom requirements beyond the National DPA.

Technical controls

Operational practices

Annual access reviews -- Review who has access to student data at least annually and revoke access for former employees and role changes.
Subprocessor inventory -- Maintain a current list of all third-party services that may access student data, and ensure each has appropriate contractual controls.
Breach response testing -- Conduct tabletop exercises or simulations at least annually to validate your incident response plan.
Parent access mechanism -- Provide a process by which parents can request access to, review, or request deletion of their child's data through the school.

Winning School District Contracts: How FERPA Compliance Unlocks the $185B Education Market

FERPA compliance is not just a legal requirement -- it is the single most important sales enabler in the EdTech market. Understanding how school district procurement works reveals why FERPA compliance is a competitive weapon.

How school district procurement works

Large school districts (50,000+ students) typically have a formal technology procurement process that includes:

Technology evaluation committee -- A cross-functional team including the CTO, curriculum directors, teachers, and often legal counsel
Product evaluation -- Assessment of educational effectiveness, usability, and integration capabilities
Security and privacy review -- Evaluation of the vendor's security posture, FERPA compliance, COPPA compliance, and state law compliance
Approved vendor list -- Products that pass all three reviews are placed on the approved vendor list, which principals and teachers can then purchase from using school or district budgets

The security and privacy review is where most EdTech companies fail. A district CTO who has been through a vendor data breach -- or who has read about one affecting another district -- will apply the highest standard of scrutiny. The vendor that comes prepared with documentation, signed agreements, and verifiable technical controls wins. The vendor that promises to "get to it" after contract signing loses.

The approved vendor list advantage

Getting on a large district's approved vendor list creates a compound advantage:

Reduced friction for individual school purchases -- Once on the list, teachers and principals can adopt your product without additional security review.
Multi-year contracts -- Districts prefer to standardize on approved vendors, leading to multi-year agreements.
Reference value -- Large district approvals serve as references for other districts. In EdTech sales, districts watch what other districts adopt.
State-level adoption -- Some states maintain statewide approved vendor lists. Getting approved at the state level opens every district in the state.

The cost of not being ready

EdTech procurement runs on a fixed calendar. Most districts have two or three approval windows per year (typically August/September and January/February). If you miss a window because your FERPA documentation is incomplete, you wait 4-6 months for the next one. In that time, a competitor who was ready takes the contract.

The math is stark. A $500K district contract delayed by six months costs the company $250K in lost revenue and potentially the deal itself, since the district may allocate budget to the vendor who was ready. Multiply that across five or ten prospective district deals, and the cost of FERPA unpreparedness reaches seven figures.

For a real-world example of how one EdTech company turned compliance readiness into a seven-figure contract win, see our EdTech case study.

FERPA Violations and Enforcement: What Happens If You're Non-Compliant

FERPA enforcement is handled by the Student Privacy Policy Office (SPPO) within the U.S. Department of Education. Understanding the enforcement mechanism is important for assessing the real risk of non-compliance.

How FERPA enforcement works

FERPA enforcement follows a complaint-driven model:

Complaint filed -- A parent, student, or other party files a complaint with the SPPO alleging that an educational institution has violated FERPA.
Investigation -- The SPPO investigates the complaint and determines whether a violation occurred.
Corrective action -- If a violation is found, the SPPO works with the institution to bring it into compliance. The SPPO may issue findings and require the institution to implement corrective measures.
Funding withdrawal -- In theory, the ultimate enforcement mechanism is the withdrawal of all federal education funding. In practice, this has never been imposed, because institutions comply with corrective action requirements rather than risk funding loss.

Why "FERPA has no teeth" is a dangerous misconception

Technology vendors sometimes downplay FERPA enforcement because the law does not provide for direct fines against vendors and the funding-withdrawal penalty has never been used. This analysis is dangerously incomplete for three reasons:

First, school districts will terminate your contract. A FERPA violation involving your product means the district violated FERPA by sharing data with a vendor that mishandled it. The district's immediate response will be to terminate the contract, demand data deletion, and notify parents. Your relationship with that district -- and potentially with every district that hears about the incident -- is over.

Second, the FTC can and does take action against EdTech companies under COPPA and Section 5. If your mishandling of student data also violates COPPA (which it likely does if your users include children under 13), the FTC has direct enforcement authority with civil penalties up to $50,120 per violation. The FTC has brought multiple enforcement actions against EdTech companies, including settlements requiring comprehensive privacy programs, regular third-party audits, and multi-million dollar penalties.

Third, state attorneys general are increasingly active. Many state student privacy laws include enforcement provisions that apply directly to vendors, with penalties that can be substantial. New York Education Law 2-d authorizes civil penalties of up to $150,000 per violation. State AG offices have dedicated privacy enforcement units that are actively investigating EdTech companies.

Fourth, the reputational damage is catastrophic. A data breach involving children's education records generates media attention, parental outrage, and school board investigations. The reputational harm to an EdTech vendor involved in a student data incident is disproportionate to the size of the breach because the victims are children.

Notable enforcement and incident examples

Edmodo (2018): The FTC took action against the EdTech platform for collecting children's personal information beyond what was necessary for educational purposes and using it for advertising. The settlement required Edmodo to implement a comprehensive privacy program.
InBloom (2014): Although not a formal enforcement action, the student data management company shut down entirely due to backlash over student privacy concerns, despite having contracts with multiple state education agencies. Public trust, once lost, could not be recovered.
Pearson (2019): The SEC brought action against Pearson for misleading investors about a data breach that exposed student data. The case demonstrated that student data incidents carry consequences across multiple regulatory domains.
Chegg (2022): The FTC ordered the education technology company to strengthen data security after four breaches exposed personal information of millions of users, many of them students. The order required annual third-party security assessments for 10 years.

FERPA + SOC 2: Why Smart EdTech Companies Pursue Both

FERPA compliance and SOC 2 are different frameworks with different origins, but they are deeply complementary -- and pursuing both simultaneously is the most efficient path to winning large school district contracts.

Why SOC 2 matters for EdTech

FERPA establishes the legal requirements for handling student data. SOC 2 provides the independent, audited verification that your security controls are designed and operating effectively. Increasingly, school districts -- especially large ones with dedicated CTOs -- require both:

FERPA compliance demonstrates that you understand student privacy law and have designed your data practices accordingly
SOC 2 Type II demonstrates that an independent CPA firm has verified your security controls over a sustained period

Together, they tell a district: "We know what the law requires, and we have independent proof that our systems enforce it."

Control overlap between FERPA and SOC 2

Many of the technical controls required for FERPA compliance map directly to SOC 2 Trust Service Criteria:

FERPA Requirement	SOC 2 Trust Service Criteria
Access controls for student data	CC6.1 - CC6.3 (Logical and physical access)
Encryption of student data	CC6.1, CC6.7 (Data protection)
Audit logging	CC7.1 - CC7.2 (System monitoring)
Incident response and breach notification	CC7.3 - CC7.5 (Incident management)
Vendor/subprocessor management	CC9.2 (Risk mitigation)
Data retention and deletion	CC6.5 (Data lifecycle management)
Change management	CC8.1 (Change management)
Employee training	CC1.4 (Commitment to competence)

If you build these controls once, designed to satisfy both FERPA and SOC 2, you avoid duplicating effort and create a compliance program that addresses both the legal requirement and the audit requirement in a single, unified framework.

The dual-framework advantage in sales

EdTech vendors who arrive at a district procurement meeting with both FERPA documentation and a SOC 2 Type II report have an immediate, measurable advantage over competitors who have one or neither. The district's CTO can point to the SOC 2 report as independent verification. The district's legal counsel can point to the FERPA documentation and signed DPA as contractual protection. The technology evaluation committee can focus on product merit rather than security risk.

For a comprehensive guide to the SOC 2 framework, including what auditors look for and how to prepare efficiently, see our SOC 2 Compliance Guide.

Frequently Asked Questions

Does FERPA apply to my company if we sell to schools?

FERPA directly regulates educational institutions, not vendors. However, if you receive student education records from a school, your handling of that data is governed by FERPA through the contractual obligations the school imposes on you. In practice, every school district will require you to comply with FERPA as a condition of doing business, and you will be contractually liable for any mishandling of student data.

Is there a FERPA certification?

No. Unlike SOC 2 or ISO 27001, there is no formal FERPA certification or audit process. FERPA compliance is demonstrated through documentation, policies, technical controls, and contractual commitments. Some organizations offer "FERPA compliance" badges or seals, but these are not recognized by the Department of Education and do not carry the weight of an independent third-party audit. This is why savvy EdTech companies pair FERPA compliance with SOC 2 Type II -- the SOC 2 report provides the independent verification that FERPA alone cannot.

What is the penalty for a FERPA violation?

The statutory penalty under FERPA is the withdrawal of federal education funding from the offending institution. This penalty has never been imposed. For EdTech vendors, the practical consequences are contract termination, reputational damage, and potential enforcement action under COPPA (FTC civil penalties up to $50,120 per violation), state student privacy laws (e.g., $150,000 per violation under New York Education Law 2-d), and Section 5 of the FTC Act (which prohibits unfair or deceptive practices).

How does FERPA apply to AI and machine learning in EdTech?

AI and ML products that process student data are fully subject to FERPA. If your AI system analyzes student performance data to generate personalized recommendations, those inputs and outputs are education records. Key considerations include: ensuring that student data used for model training falls within the permitted educational purpose, not using student data to train models that serve non-educational commercial purposes, providing transparency about how AI-generated assessments are produced, and ensuring that AI-generated records about students are accessible to parents under FERPA's inspection rights.

Can parents access the student data my platform stores?

Yes. Under FERPA, parents have the right to inspect and review their child's education records. This includes records maintained by a vendor on behalf of the school. In practice, parents typically exercise this right through the school (not directly with the vendor), but your platform must be capable of providing the school with a complete export of a student's data upon request.

What is the difference between FERPA and COPPA for EdTech?

FERPA governs the privacy of education records maintained by educational institutions and their agents. COPPA governs the online collection of personal information from children under 13. Both apply to most K-12 EdTech products, but through different mechanisms: FERPA obligations flow from the school-vendor contract, while COPPA obligations apply directly to the vendor. The school consent mechanism under COPPA allows schools to authorize data collection for educational purposes, but this does not eliminate the vendor's direct obligations under COPPA to maintain reasonable security, limit data collection, and avoid commercial use.

Do I need a SOC 2 report to sell to school districts?

Not all school districts require SOC 2, but the trend is moving firmly in that direction. Small districts (under 10,000 students) may accept self-reported security questionnaires. Medium districts (10,000-50,000 students) increasingly expect SOC 2 or equivalent third-party assurance. Large districts (50,000+ students) almost universally require SOC 2 Type II reports as part of their vendor approval process. If your growth strategy targets large districts or state-level adoption, a SOC 2 report is effectively required.

How long does it take to become FERPA compliant?

For an EdTech company starting from scratch, achieving comprehensive FERPA compliance -- including policies, technical controls, data sharing agreement readiness, and staff training -- typically takes 4-8 weeks with focused effort and expert guidance. If you are also pursuing SOC 2 simultaneously (which is recommended), a combined program typically takes 6-10 weeks. The timeline depends on your existing security posture, the complexity of your data architecture, and whether you have expert support.

Get FERPA-Ready and Win School District Contracts

FERPA compliance is the key that opens the $185 billion K-12 education technology market. But it is not a box you check once. It is a continuous practice of privacy-respecting design, rigorous data governance, transparent contractual commitments, and verifiable technical controls.

The EdTech vendors who win are not the ones who scramble to meet compliance requirements after a district asks for them. They are the ones who arrive at the procurement table with documentation ready, agreements prepared, technical controls verified, and -- increasingly -- a SOC 2 Type II report that provides independent proof.

QuickTrust helps EdTech companies achieve FERPA compliance, COPPA compliance, and SOC 2 certification in a single, coordinated program. Our team has guided EdTech companies through the exact process described in this guide -- from policy development and technical implementation to National DPA preparation and SOC 2 audit management. We understand the intersection of student privacy law and security compliance because we have done it repeatedly for companies like yours.

Whether you are preparing for your first school district contract or scaling to statewide adoption, we can help you get there faster -- without pulling your engineering team off the product.

Start your EdTech compliance program -- quicktrustapp.com