Is Your EdTech FERPA Compliant? What Schools Need to Know

Every year, schools adopt dozens of new apps and platforms. Reading programs, math games, communication tools, behavior trackers, assessment platforms. Each one collects some form of student data. And each one introduces a potential FERPA compliance risk that most schools never evaluate.

FERPA (the Family Educational Rights and Privacy Act) is the federal law that governs how schools handle student education records. It's been around since 1974, but the rise of cloud-based EdTech has created compliance challenges that the law's authors never imagined.

Here's what you need to know.

What FERPA Actually Requires

FERPA applies to any school that receives federal funding (which is nearly all public schools). The law gives parents rights over their children's education records and restricts how schools can share those records.

The key provisions that matter for EdTech:

1. Consent before disclosure

Schools generally cannot disclose personally identifiable information (PII) from a student's education record without written parental consent. There are exceptions, the most relevant one being the "school official" exception, which allows disclosure to third-party service providers who meet certain conditions.

2. The school official exception

Under FERPA, a school can share student data with a third-party company (like an EdTech vendor) without parental consent if:

• The vendor performs a function the school would otherwise do itself
• The vendor is under the school's direct control regarding use and maintenance of the data
• The vendor doesn't use the data for any purpose other than the one specified in its agreement with the school
• The vendor meets the criteria set forth in the school's annual FERPA notification

3. Data security

While FERPA doesn't specify exact security standards (like "you must use AES-256 encryption"), it does require schools to protect education records from unauthorized access. If a school shares data with a vendor that has weak security, the school bears responsibility for any resulting breach.

Red Flags: When an EdTech Tool Is NOT Compliant

Here are the most common compliance failures in educational technology:

Using student data for advertising

If a platform shows ads to students or parents, or uses student behavioral data to inform ad targeting elsewhere, that's a FERPA violation. Student education records cannot be used for commercial purposes outside the educational function.

Some platforms that are "free for teachers" monetize through advertising or data brokerage. Free isn't free if the business model depends on student data. This is one of the key factors to evaluate when choosing a classroom behavior tracking tool.

No Data Processing Agreement (DPA)

A compliant vendor should be willing to sign a Data Processing Agreement (sometimes called a Data Privacy Agreement) that specifies:

• What data is collected
• How it's stored and protected
• Who has access
• How long it's retained
• How it can be deleted
• That the vendor won't use the data for non-educational purposes

If a vendor won't sign a DPA, that's a significant red flag.

No clear data deletion policy

Under FERPA, parents have the right to request that education records be amended or deleted. If a vendor can't tell you how data is deleted, or if data persists after a teacher or school removes it, the tool likely doesn't meet FERPA requirements.

Data stored outside the U.S. without disclosure

FERPA doesn't explicitly prohibit international data storage, but many state student privacy laws do. If a vendor stores data overseas, the school needs to know and evaluate whether that complies with state law.

Weak or unspecified encryption

A vendor that can't tell you how student data is encrypted, at rest and in transit, hasn't thought seriously about security. At minimum, you should see:

• Encryption in transit: TLS 1.2 or higher for all data transmission
• Encryption at rest: AES-256 or equivalent for stored data
• Access controls: Role-based access so that only authorized users can view student data

Questions Every School Should Ask

Before adopting any EdTech tool that handles student data, ask the vendor these questions:

1. Will you sign our district's Data Processing Agreement? If they hesitate, walk away.

2. Do you sell, share, or use student data for purposes other than the educational service? The answer needs to be an unqualified no.

3. How is data encrypted? You want to hear "AES-256 at rest, TLS in transit" or equivalent.

4. Where is data stored? U.S.-based cloud infrastructure (AWS, Google Cloud, Azure) is the standard. Know if data crosses borders.

5. Can we delete all data when we stop using the service? The answer should be yes, with a clear process and timeline.

6. Who at your company can access student data? Access should be limited and auditable.

7. What happens in a data breach? The vendor should have a documented incident response plan and commit to notifying the school within a specified timeframe (72 hours is standard).

8. Are you SOC 2 certified or have you completed a third-party security audit? This isn't required by FERPA but demonstrates that the vendor takes security seriously.

Don't Forget COPPA

FERPA isn't the only federal law that applies to EdTech in schools. If your students are under 13 (which covers most elementary and many middle school students) the Children's Online Privacy Protection Act (COPPA) also comes into play.

COPPA restricts how online services collect, use, and disclose personal information from children under 13. In a school context, the key points are:

Schools can consent on behalf of parents, but only for educational purposes. Under the FTC's COPPA rule, a school can authorize an EdTech vendor to collect student data without individual parental consent, as long as the data is used solely for a school-authorized educational purpose. This is similar to FERPA's "school official" exception, but it's a separate legal requirement.

The vendor must have a clear privacy policy. COPPA requires that online services directed at children (or that knowingly collect data from children) post a clear, comprehensive privacy policy describing their data practices.

Data collection must be limited to what's necessary. COPPA's "data minimization" principle means a vendor shouldn't collect more information than it needs to provide the educational service. If a behavior tracking tool asks students for their birthday, home address, and photo when all it needs is a name and class assignment, that's a red flag.

Parental rights apply. Parents have the right to review the personal information collected from their child and to request deletion, similar to FERPA, but enforced by the FTC rather than the Department of Education.

In practice, FERPA and COPPA often overlap for elementary-age students. The safest approach is to evaluate EdTech tools against both laws: ask the vendor whether they comply with COPPA in addition to FERPA, and look for explicit mention of COPPA in their privacy policy or DPA.

State Laws Add Another Layer

FERPA is the federal floor, but many states have enacted stricter student privacy laws:

• California (SOPIPA): Prohibits using student data for non-educational commercial purposes and requires data deletion upon request
• New York (Education Law 2-d): Requires a Data Privacy and Security Plan and a Parents' Bill of Rights
• Colorado, Connecticut, Illinois, and others have similar or stronger provisions

If your school is in a state with additional privacy protections, the EdTech tools you use need to comply with both FERPA and state law.

How We Approach This at Evident

Since this blog is published by Evident, it's fair to share how we handle the same questions we recommend you ask every vendor. We built Evident with privacy as a design constraint, not an afterthought, and we're happy to be evaluated by the same checklist above.

We encrypt all student data at rest with AES-256 and in transit with TLS. We make money from subscriptions. We never sell, share, or monetize student data, and we don't show ads. We offer a Data Processing Agreement for any school or district that requires one, and we comply with COPPA for students under 13. Teachers own their data and can export (CSV or PDF) or delete it at any time. When a teacher deletes a student or closes their account, the data is permanently removed. Student data is stored in the region your school chooses: U.S.-based cloud infrastructure by default, or a dedicated EU deployment where records are stored and processed in the European Union. Our privacy policy explains our practices in plain English.

If you're evaluating behavior tracking tools specifically, our comparison of ClassDojo alternatives covers privacy alongside other criteria.

The Practical Takeaway

FERPA compliance isn't a checkbox exercise. It's an ongoing responsibility. Every EdTech tool your school uses should be evaluated against the same criteria:

1. Is student data protected with strong encryption?
2. Does the vendor sign a DPA?
3. Is the business model transparent (not ad-supported or data-brokered)?
4. Can data be exported and deleted?
5. Does the vendor comply with your state's privacy laws?

If a tool fails any of these tests, the time savings it provides aren't worth the risk.

Frequently Asked Questions

Does FERPA apply to a free tool a teacher signs up for on their own? Yes, if student education records go into it. FERPA attaches to the records, not to the purchase order, which is why a free classroom tool adopted without district review is a common source of exposure. Price has nothing to do with it.

What is a DPA, and do we need one for every vendor? A Data Processing Agreement is the contract that binds a vendor to how they may handle student data, including deletion and breach notification. You need one with any vendor holding education records. A vendor that won't sign one, or that only offers unmodifiable terms of service, is answering your question. Ours is published at /privacy/dpa so you can read it before talking to anyone.

Is "we don't sell student data" enough of a commitment? No. Ask what happens to the data instead: is it used to train models, shared with subprocessors, retained after account closure, or used for advertising to families. "We don't sell" is compatible with several practices schools would still object to.

Who is responsible if a vendor has a breach, the school or the vendor? Practically, both, and the school is the one families call. Under FERPA the district remains responsible for the records it discloses to a vendor under the school official exception, which is exactly why the DPA and the vendor's security posture are the district's business rather than the vendor's private matter.

Where should sensitive counselor notes live? Not in the same bucket as classroom behavior data, and not in a second unofficial system either. Access should follow role rather than convenience. We work through the options in where school counselors should keep notes.

What about schools outside the US? FERPA is US law. International schools usually face GDPR or a national equivalent instead, and the questions change: data residency, lawful basis, and a DPO review of the DPA. We cover that in GDPR and student data for international schools and the EdTech data protection checklist.

We've found a tool that fails this checklist but teachers love it. Now what? Document the gap, ask the vendor for the specific remedy (a DPA, a deletion commitment, a subprocessor list), and set a date. Most vendors that fail a checklist fail it on paperwork rather than on architecture, and a written request with a deadline resolves a surprising number of them.