FERPA Compliance for EdTech Vendors: What You Actually Need to Know

FERPA in 60 Seconds

The Family Educational Rights and Privacy Act — codified at 20 U.S.C. § 1232g and implemented through regulations at 34 CFR Part 99 — is the foundational federal law governing the privacy of student education records. Enacted in 1974, FERPA gives parents (and eligible students over 18) the right to access their education records, request corrections, and control who those records are shared with.

Here is the single most important thing to understand about FERPA if you build or sell education technology: FERPA does not directly regulate vendors. It regulates schools. Specifically, it applies to any educational institution that receives funding under any program administered by the U.S. Department of Education — which is virtually every public school and most private institutions that accept federal student aid.

The law tells schools what they can and cannot do with student records. Vendors enter the picture only when a school decides to share records with them. This distinction matters enormously for compliance planning, because the obligations flow from the school's decision to share, not from the vendor's desire to collect.

FERPA violations can result in the withdrawal of federal funding from the school — the nuclear option that makes district procurement teams extremely cautious about vendor relationships. No school has ever actually lost its federal funding over a FERPA violation, but the theoretical risk drives a compliance culture that every edtech vendor must navigate.

The School Official Exception

If FERPA generally requires parental consent before sharing education records, how does any edtech vendor operate? The answer is 34 CFR § 99.31(a)(1) — the "school official" exception. This provision allows schools to share education records without parental consent when three conditions are met:

1. The vendor performs an institutional service or function that the school would otherwise use employees to perform. Running a learning management system, administering assessments, managing student information — these are all institutional functions.
2. The vendor is under the direct control of the school with respect to the use and maintenance of education records. In practice, this means a contract that specifies what data the vendor can access, how they can use it, and what happens when the relationship ends.
3. The vendor uses the data only for the purposes for which it was shared. No selling student data to third parties. No using it for targeted advertising. No building profiles for purposes unrelated to the school's educational mission.

This exception is the legal basis for virtually all edtech vendor relationships with schools. The mechanism that formalizes it is the Data Processing Agreement (DPA) — a contract that documents the vendor's commitments on data use, security, breach notification, and deletion. If you've ever seen a district send a vendor a 15-page DPA before approving a software purchase, this is why.

What Actually Constitutes "Education Records"

Not everything a school has is an education record. The definition at 34 CFR § 99.3 is specific: education records are records that are (1) directly related to a student and (2) maintained by an educational agency or institution, or by a party acting for such agency or institution.

Understanding what falls inside and outside this definition is critical for vendors assessing their FERPA exposure:

The distinction between student-level and school-level data is where many vendors over-complicate their compliance posture. If your platform uses only publicly available federal datasets — NCES enrollment data, CCD survey responses, USAC E-Rate filings, state assessment results published at the school level — you are not handling education records under FERPA. Period.

What District Procurement Teams Look For

Regardless of your actual FERPA exposure, district procurement offices have standardized their vendor evaluation processes around a common set of compliance checkpoints. If you sell to schools, you will be asked about all of these — even if some don't technically apply to your product.

• Signed Data Processing Agreement. The Student Data Privacy Consortium (SDPC) National DPA is the gold standard. Many states have adopted it or created state-specific versions (California, New York, Illinois, Colorado, and others). If a district hands you a DPA, sign it. If they don't, offer one proactively.
• Data handling practices documentation. A clear, public-facing document that explains what data you collect, how you store it, who has access, and how long you retain it. This should not require a lawyer to understand.
• Breach notification commitment. Most districts want a 72-hour notification window. Some states mandate specific timelines by law. Document your commitment and the contact path for incident reports.
• Clear statement of data collected and not collected. Procurement teams love specificity. "We collect school-level aggregate data from public federal sources. We do not collect, store, or process any student personally identifiable information." That sentence alone resolves 80% of questions.
• Sub-processor list. Who else touches data in your system? Cloud hosting providers, analytics services, support tools — list them. Districts need to evaluate the full data supply chain.
• Data deletion procedures. What happens to the district's data when the contract ends? Define retention periods and deletion timelines. Most DPAs require deletion within 30–60 days of termination.
• Annual security assessment or SOC 2 report. SOC 2 Aligned is the benchmark that signals professional-grade security practices. If you're early-stage and don't have SOC 2 yet, document your security controls in a publicly available format.
• State-specific compliance. Several states have enacted student data privacy laws that go beyond FERPA. Illinois SOPPA, New York Education Law 2-d, California AB 1584, and Colorado HB 16-1423 each impose additional requirements. If you sell nationally, you need to track compliance across all applicable state laws.

The ThinkKits Approach: No Student PII by Design

When we designed the ThinkKits platform, we made a deliberate architectural decision: no student personally identifiable information ever enters our system. This wasn't an afterthought or a compliance workaround — it was a foundational design principle that shapes everything from our data model to our sales process.

Here's how it works. The ThinkKits platform is a school intelligence tool built entirely on publicly available federal data. Our Knowledge Graph contains — school profiles constructed from NCES Common Core of Data, USAC E-Rate filings, Census Bureau demographic data, and state-published school report cards. Every data point in our system describes a school, district, or state — never a student.

The practical implications for compliance are significant:

• No FERPA-regulated data to protect. Since we never receive education records, the core FERPA privacy framework simply doesn't apply to our data operations. There are no student records to secure, no consent requirements to manage, no breach notifications to plan for (at least not for student data).
• No DPA technically required. A Data Processing Agreement governs how a vendor handles the school's data. If we never receive the school's data, there's no processing to agree on. That said, we sign DPAs anyway — because districts expect it, and transparency builds trust faster than legal technicalities.
• No state student data privacy law exposure. Illinois SOPPA, New York Ed Law 2-d, California AB 1584 — all of these regulate the handling of student data by edtech vendors. If you don't handle student data, the regulatory surface area collapses to near zero.
• Dramatically simpler procurement. The typical district technology procurement process takes 60–120 days, with 30–40% of that time consumed by security and privacy review. When the answer to "what student data do you store?" is "none," the review collapses to a verification exercise rather than a compliance negotiation.
• Faster security reviews. Security questionnaires from districts routinely run 100–200 questions. When half of those questions relate to student data handling, and your answer to all of them is "not applicable — we don't process student data," the review cycle shortens dramatically.

Building Trust Even Without FERPA Exposure

Even if your product genuinely doesn't touch student data, you will still face scrutiny from district procurement teams. They are conditioned by experience to assume every vendor handles student data until proven otherwise. Here's how to build trust proactively rather than reactively.

1. Publish a Clear FERPA Statement

Don't let procurement teams guess your FERPA posture. Publish a clear, accessible statement on your website that explains your relationship to FERPA — even if that relationship is "not applicable." Explain why it's not applicable in plain language. "ThinkKits does not collect, store, or process student personally identifiable information. Our platform operates exclusively on publicly available federal data sources. FERPA regulation of student education records does not apply to our data operations." That's the whole statement. Put it on your website.

2. Sign DPAs Anyway

When a district sends you a DPA, don't push back with "we don't need one." Sign it. The DPA is as much a trust signal as it is a legal instrument. By signing, you're telling the district: "We take your data privacy concerns seriously enough to put our commitments in writing, even when the law doesn't require it." That posture accelerates procurement.

3. Publish Your Security Practices

Maintain a public-facing security page that documents your infrastructure, encryption practices, access controls, incident response procedures, and vendor management policies. Even without student data, you still handle school-level data, user credentials, and business information that deserves professional security treatment. Document that treatment publicly.

4. Maintain a Trust Center

A Trust Center is a single page where procurement teams can find everything they need: FERPA statement, security documentation, DPA template, sub-processor list, SOC 2 Aligned report (or security questionnaire responses), state compliance status, and contact information for your security team. The easier you make the review process, the faster it goes.

5. Be Proactive, Not Reactive

Don't wait for the RFP or the procurement questionnaire to surface your compliance posture. Include your Trust Center link in sales materials, product demos, and email signatures. When a prospect asks "how do you handle student data?", the answer should already be in their inbox before they ask the question. Proactive transparency is the fastest path to district trust.

Related Articles

• How Title I Schools Can Save on Manipulatives
• 5 Funding Sources Every School Forgets About
• What School Board Minutes Reveal About Buying Decisions