Is GPTZero FERPA Compliant?
GPTZero cannot be "FERPA certified," because FERPA (20 U.S.C. § 1232g) certifies no software; it binds the school district that submits the data. The sharper fact for a detector is this: when a teacher uploads a student's essay for scanning, that essay is very often an education record, so the real FERPA question is what GPTZero does with that text, how long it keeps it, and whether a signed agreement actually covers it. GPTZero states it does not store student "education records," which is a vendor interpretation a district should weigh, not a settled legal conclusion.
Quick Answer: No AI tool is "FERPA certified," and GPTZero does not hold such a credential, because FERPA governs districts rather than vendors. A student essay submitted to GPTZero is generally an education record, even though the teacher, not the student, does the submitting. GPTZero states it collects only the minimum needed to run a scan and does not store what it treats as an "education record," relying on institutions to secure consent. Whether that framing holds for your district depends on a signed Data Processing Agreement and its retention terms, not on the compliance line on GPTZero's website.
This is a narrower question than whether GPTZero is safe to use, or whether it satisfies COPPA. The false-positive research and due-process risk are handled in Is GPTZero Safe for Students?, and the under-13 consent mechanics in Is GPTZero COPPA Compliant?. Here the focus is strictly FERPA: the education record, its retention, and the contract that governs both.
The FERPA Certification Myth, Applied to a Detector
FERPA is a law about how schools handle student records, and it offers no certificate for a detector, a chatbot, or any other product to earn. A "FERPA compliant" claim on GPTZero's site is a description of contractual willingness, not a government seal, for the same reason it is on every other vendor page: FERPA binds the funded school district, and the US Department of Education runs no vendor-certification program.
That reframes the question productively. Instead of asking whether GPTZero "is" FERPA compliant, a district should ask whether GPTZero's terms let the district stay FERPA compliant while using it. The difference is not pedantic:
- A certification would be a property of the product, verified once and displayed.
- A contract is a relationship with your district, enforceable only for you, and only as strong as its actual language.
The pillar guide, AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026), walks through why that certification-versus-contract distinction is the load-bearing fact in every vendor-compliance question, detectors included.
A Submitted Student Essay Is Usually an Education Record
The essay a teacher uploads to GPTZero is, in most cases, an education record: it is directly related to an identifiable student and maintained by the school. That the teacher does the uploading, rather than the student, does not change what the document is. It changes who handed it to the vendor, which is a COPPA-relevant detail, not a FERPA-erasing one.
This is the fact a "the student never logged in, so FERPA does not apply" summary gets wrong. FERPA attaches to the record, wherever it travels, once the school shares it with a third party.
Why the Essay Itself Qualifies
An education record under FERPA is information directly related to a student and maintained by the school or a party acting for the school. A graded or gradeable essay is a textbook example. When a teacher submits it to an outside service for analysis, the school is disclosing an education record to a third party, which triggers FERPA's disclosure rules and, with them, the school-official exception at 34 CFR § 99.31(a)(1).
GPTZero's "We Don't Store Education Records" Claim, Read Closely
GPTZero's published student-privacy materials state that it does not store student "educational records" and receives only the minimally required information from teachers to perform a scan (GPTZero, 2025). That is a reasonable position for the company to take, and it deserves the same scrutiny as any vendor's self-interpretation of a law that binds the district rather than the vendor.
Two things can both be true at once:
- GPTZero may not treat a stored similarity report as an "education record" in its own systems.
- The underlying essay, and a result tied to an identifiable student, can still be an education record from the district's standpoint, which is the standpoint FERPA actually cares about.
Whether a stored GPTZero result counts as an education record is a genuinely close question that turns on how a specific institutional agreement characterizes it, not on the public privacy page alone. The table below separates what GPTZero states from what a district still needs to pin down.
| Data element | GPTZero's stated practice | What a district should still confirm |
|---|---|---|
| The submitted essay text | Stored on GPTZero's servers to run detection | Whether the DPA limits use of that text to scanning only |
| A stored similarity result | Not treated as an "education record" by GPTZero | Whether the district agrees, given the result ties to a named student |
| Account details (teacher name, email, institution) | Collected to manage submissions | Whether student self-check accounts, if enabled, collect the same |
| Aggregated or anonymized text | May be used to improve detection models | Whether an institutional agreement can opt out of that use |
What the Parent's Right to Inspect Means for a Detector
Because a submitted essay is an education record, FERPA's parental right to inspect and review can extend to what a detector did with it. A parent can ask to see the records the school maintains about their child, and a scan tied to that child sits inside that request, not outside it. This is the FERPA angle most easily missed, because a detector feels like a passive check rather than a records system.
Three practical consequences follow, and a district should be ready for each:
- Retrievability matters. The school needs a way to show what was submitted and what came back, which means knowing where that data actually lives and who can pull it.
- Amendment rights can apply. If a stored result is inaccurate and treated as a record, a parent may ask the school to correct or annotate it, which presumes the district can reach the data to do so.
- A shrug is not a compliant answer. "The detector had it" does not satisfy the school's obligation to account for a student's records, which is why the account type and the agreement behind it matter before the first scan.
The Retention Question FERPA Actually Cares About
FERPA does not set a fixed retention period, but it does make the district responsible for knowing one, and GPTZero does not publish a single number that answers it. Retention depends on account type and on whether deletion is actively requested, which is a looser posture than a hard "we delete after 90 days" and exactly the kind of gap a district should close in writing.
Here is what GPTZero's own materials describe, sorted by the account type that governs the data.
| Account type | Retention posture (per GPTZero) | FERPA implication for a district |
|---|---|---|
| Free or individual paid | Submission history can be deleted from the dashboard or via support | A personal account is governed by public terms, not your district's agreement |
| Institutional or education contract | Retention terms live in the separate signed agreement | This is where a district sets an auditable, specific timeline |
| On account termination | Deactivation and deletion from active databases, with standard carve-outs | Confirm the carve-outs and the actual deletion mechanism exist |
| Deletion on request | Users may request deletion of a student's personal information at any time | Confirm turnaround time and whether it is contractually guaranteed |
GPTZero states that users may request deletion of their students' personal information at any time, and that institutional agreements carry stricter, separately negotiated terms than the public tier (GPTZero, 2025). The practical lesson is the one the pillar checklist puts ahead of any general compliance claim: get the written retention and deletion timeline before rollout, not the marketing line.
Why the 2025 Regulatory Backdrop Raises the Bar
A district evaluating a detector's retention posture in 2026 is doing so against tighter expectations than a few years ago. The FTC published its first COPPA Rule amendments since 2013 in the Federal Register on April 22, 2025, adding an explicit requirement for a written, published data-retention policy, with most provisions requiring compliance by April 22, 2026 (FTC, 2025).
That amendment is a COPPA rule rather than a FERPA one, but it raises the ambient standard for what "we retain data responsibly" has to mean in a contract. A district reviewing GPTZero should expect a specific, written retention timeline rather than a general assurance, because the regulatory floor for vendors handling children's data has moved, and a loose posture reads differently now than it once did.
The Detection-Engine Question FERPA-Minded Districts Miss
FERPA follows the data through the whole chain, not just to GPTZero's front door, so a district should ask what sits behind the detector. A scanning-only or no-training commitment protects a student's essay only if it extends to any underlying detection engine or subprocessor the text passes through, and only if that extension is in writing.
This mirrors the subprocessor problem the pillar guide flags for generative AI tools generally: the vendor a district contracts with is often not the only party that touches the data. For a detector, the questions worth asking directly are narrow but important.
- Does submitted text leave GPTZero's own systems for any third-party processing, and if so, under what terms?
- Does the scanning-only commitment bind that layer too, or does it stop at GPTZero's own use of the text?
- Does a subprocessor change trigger notice to the district, so a shift in data practices does not happen silently after the DPA is already signed?
None of these are exotic. They are the ordinary chain-of-custody questions any student-data vendor should be able to answer, and a detector is not exempt simply because its job is analysis rather than long-term storage.
Teacher-Submitted vs Student Self-Check: The Posture Changes
The FERPA analysis shifts depending on whether a teacher submits the essay or a student runs a self-check inside GPTZero directly. The default classroom workflow keeps the teacher as the party interacting with the tool, which is cleaner. An enabled student self-check feature moves a child closer to being a direct account holder, which deserves its own line in a review.
- Teacher-submitted scanning. A teacher collects work through Google Classroom or an upload, then submits it. The school is disclosing a record to a vendor, governed by the school-official exception and the DPA.
- Student self-check accounts. Where an institution enables them, a student checks their own draft before submitting, which creates a more direct student-to-vendor relationship and a separate consent and records question.
- API or LMS integrations. Submissions routed through a third-party platform carry their own data-handling terms, which a district should confirm rather than assume match the consumer web product.
A Grade 8 English Records Scenario, Walked Through
Say you teach Grade 8 English and a parent asks, mid-semester, what happened to their child's argumentative essay after you ran it through a detector. That is a FERPA question about an education record, and a careful answer depends on choices made before the essay was ever submitted.
- Know which account you submitted through. If it was your school's institutional GPTZero account, the retention and use terms are the ones your district negotiated, and you can point to them.
- Know what was stored. The essay text was stored to run the scan; whether a result was retained depends on the account and the agreement.
- Be able to route a deletion request. GPTZero states deletion can be requested, so the parent's question has a real answer if your district knows who submits that request and how.
- Strip identifying detail as a default habit. A header with a student's full name travels with an uploaded file, so pasting plain text or removing the header shrinks what the record even exposes.
The operational version of that habit, which account to use and what to strip, is covered in depth in GPTZero and Student Data Privacy: What Teachers Should Know. The point for FERPA is that the answer to "what happened to my child's essay" should never be a shrug.
The District's FERPA Checklist for a Detector
Treat GPTZero's compliance page as the first question, not the final answer. A short, ordered due-diligence pass turns a marketing claim into a documented posture, with written responses rather than verbal reassurances.
- Request the institutional Data Processing Agreement, and confirm it addresses retention, deletion, and any use of submitted text for model improvement.
- Decide whether a stored result is an education record for your district's purposes, and get the DPA to treat it accordingly rather than leaving it to the vendor's interpretation.
- Confirm whether student self-check accounts are enabled, since that single choice changes whether a child interacts with the tool directly.
- Ask for the retention number in writing. "We may retain data" is not auditable; "we retain submitted text for X months unless deletion is requested" is.
- Check your state statute separately. California's SOPIPA (2014) and Illinois's SOPPA (2021) can require more than FERPA alone, so a FERPA-satisfying contract can still fall short of a state rule.
- Route the contract through your student-data-privacy officer or legal counsel, not procurement alone, before expanding beyond a pilot.
Where a detector sits at the end of an assignment, a teacher building the assignment has separate FERPA leverage: keep student data out of the content-creation step entirely. A teacher could use EduGenius to generate a scaffolded, multi-draft Grade 8 writing prompt from a class profile, with staged checkpoints, so process evidence exists without a scan and no student logs into the generation tool at all. That does not replace a detector, but it shrinks how much identifiable student work ever needs to leave the classroom for outside analysis.
Pro Tips and What to Avoid
The recurring mistake is treating a detector as exempt from the review any other student-data vendor gets. A few habits keep the FERPA question grounded.
- Separate the FERPA claim from the accuracy claim. GPTZero's stated detection numbers are vendor claims about performance, a different question from how it handles the record; the accuracy debate lives in Is GPTZero Safe for Students?.
- Do not conflate GPTZero's FERPA and COPPA positioning. They are legally distinct, and a statement about one does not settle the other, as Is GPTZero COPPA Compliant? details.
- Do not assume the free tier and an institutional license carry the same terms. Retention and use commitments are typically stronger under a signed contract.
- Do not let a stored essay outlive its purpose. Confirm a deletion path exists and is used, rather than assuming submissions quietly disappear.
For contrast, it helps to see how differently the FERPA question lands across tools. Is Diffit FERPA Compliant? covers a teacher-only tool that states it collects no student data, so there is almost no record to govern, the opposite end of the spectrum from a detector that ingests a student's full essay. A district comparing several classroom tools against one evidence standard may also find SchoolAI vs Khanmigo: Which Is Better for Teachers? useful.
Key Takeaways
- No vendor is "FERPA certified," GPTZero included, because FERPA (20 U.S.C. § 1232g) binds the school district, not the software it uses.
- A submitted student essay is usually an education record, even though a teacher does the submitting, so FERPA's disclosure rules and the school-official exception (34 CFR § 99.31(a)(1)) apply.
- GPTZero states it does not store student "education records" and collects only minimal scan data, a vendor interpretation a district should weigh against its own reading of what the stored essay and result represent.
- GPTZero publishes no single retention period; terms depend on account type, and institutional contracts govern the specific timeline a district can actually audit.
- Teacher-submitted scanning and student self-check accounts carry different FERPA postures, so a district should confirm which one its rollout uses.
- The signed Data Processing Agreement, not the compliance page, is the enforceable document, and it should specify retention, deletion, and whether a stored result counts as a record.
- The district holds the FERPA obligation throughout; GPTZero can offer supportive terms, but responsibility for the education record stays with the school.
Frequently Asked Questions
Is GPTZero officially FERPA certified?
No. FERPA has no certification for software vendors, because it legally binds schools and districts rather than the companies they use. GPTZero states it complies with FERPA and does not store student "education records," but that is a vendor description backed by an institutional contract, not a government-issued credential a district can rely on by itself.
Is a student's essay submitted to GPTZero an education record?
Usually yes. An essay directly related to an identifiable student and maintained by the school is a classic education record, and a teacher submitting it to an outside service is the school disclosing that record to a third party. That the student did not personally upload it does not remove FERPA's coverage of the document.
How long does GPTZero keep submitted student writing?
GPTZero does not publish one fixed retention period. Free and individual accounts can generally delete submission history directly, while institutional accounts are governed by a separate signed agreement that should state the exact retention and deletion timeline. A district should get that number in writing rather than relying on the public policy.
Does GPTZero's claim that it holds no education records settle the FERPA question?
No. That is GPTZero's interpretation of its own systems, and it does not bind a district's reading of the law. The submitted essay, and a stored result tied to a named student, can still be education records from the district's standpoint, which is why the Data Processing Agreement should define how they are treated.
What should a district get in writing before using GPTZero?
Request the institutional Data Processing Agreement and confirm it specifies retention, deletion turnaround, whether submitted text can be used to improve models, and whether student self-check accounts are enabled. Verify the terms against your state's student-privacy statute, since laws like SOPIPA and SOPPA can require more than FERPA alone.