A Student Data Privacy Compliance Checklist for AI Tools in Schools

A student-data-privacy checklist for AI tools tracks the information itself, not the infrastructure around it, across six stages: what gets collected, whether it's the minimum needed, what it's used for, how long it's kept, who it's shared with, and how it gets deleted. Run any AI tool through those six questions, in that order, before it touches a real class roster.

Quick Answer: A complete student-data-privacy checklist follows the data through its full lifecycle: collection (what's actually gathered), minimization (does the tool need it), use limitation (is it used only for the stated purpose), retention (how long it's kept and under what written policy), third-party sharing (which subprocessors touch it), and deletion (what happens on request, withdrawal, or graduation). This spans FERPA, COPPA, and state student-privacy law in one unified pass, rather than treating each law as a separate review.

This is deliberately not a security-controls checklist and not a COPPA-only checklist. For the underlying legal framework this checklist assumes, why FERPA binds schools and COPPA binds vendors differently, see AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026). For encryption standards, access control, and vendor security audits, see EduGenius's A Data Security Compliance Checklist for AI Tools in Schools, which covers the infrastructure a tool runs on. For the under-13 consent mechanics specifically, see A COPPA Compliance Checklist for AI Tools in Schools. This checklist sits between them: it's about what happens to the data itself, at every grade level, once a tool has cleared both of those reviews.

Which Checklist Do You Actually Need?

Three EduGenius checklists cover related but distinct ground, and picking the wrong one wastes a reviewer's time. This table exists to route you to the right one before you start.

A single AI tool may need all three passes before full rollout. This one is the piece most districts skip, because it doesn't map neatly onto a single law the way COPPA consent or FERPA disclosure rules do.

The Six-Stage Student Data Lifecycle

Every AI tool that touches student information moves that data through the same six stages, whether or not the vendor's documentation says so explicitly. Naming each stage, and the specific question to ask at each one, turns a vague privacy concern into something checkable.

Stage 1: Collection

Start by mapping every field the tool actually gathers, not the fields you assume it gathers. A worksheet generator that only ever sees a grade level and subject collects almost nothing identifiable; an AI reading-fluency tool that records a student's voice collects something the FTC's 2025 COPPA amendments now classify as biometric personal information in its own right (FTC, 2025).

Walk each tool through these questions:

1. Does a student type or speak directly into the tool, or does a teacher operate it on the class's behalf?
2. Does the tool capture a name, photo, voice sample, or handwriting image, or only an anonymized response?
3. Does the tool assign a persistent identifier that could re-identify the same student across sessions?
4. Is any of this collection happening through an embedded third-party script the vendor didn't directly build?

Even tools in the same category can answer these differently. A game-based review platform like Kahoot may collect a display name and a running score tied to a game-pin session; a flashcard app may collect a full account profile if a student creates one. (See Kahoot and Student Data Privacy for a tool-specific breakdown.) Stage 1 has to be run per tool, not assumed from the category it belongs to.

A teacher-mediated workflow, where a class profile drives content generation rather than individual student logins, tends to collect far less by design. EduGenius, for instance, is built around a teacher setting a grade level, subject, and ability range in a class profile, then generating quizzes, worksheets, and other materials from that profile rather than having students type into the tool directly, which narrows Stage 1's answer before the checklist even continues. That's a structural choice worth noting, not a substitute for actually checking the remaining five stages.

Stage 2: Minimization

Data minimization asks a narrower question than collection does: of everything the tool gathers, does it actually need all of it for the task at hand? A field collected "in case it's useful later" is the opposite of minimization, and it's the single most common gap this stage catches.

• Necessary: a grade level, needed to generate age-appropriate content.
• Borderline: a full class roster with student names, when an anonymized ID would do the same job.
• Unnecessary: a home address or parent contact information, requested by a tool that has no operational reason to need it.

FERPA's "legitimate educational interest" standard, the same test that governs which school employees can access a record, maps cleanly onto this stage: if a human employee wouldn't need a field to do the job, an AI tool processing that same task usually doesn't either. A text-leveling tool like Diffit is a useful test case here, since differentiating a reading passage by level genuinely needs a student's reading level but not their name; see Diffit and Student Data Privacy for how that specific tool draws the line.

Stage 3: Use Limitation

Data collected for one purpose drifting into use for another, most often model training or product analytics, is where "compliant at signing" quietly becomes "non-compliant in practice." This stage asks whether the vendor's actual behavior matches the purpose the district authorized.

Two questions cut to the center of it:

• Does the vendor train its underlying model on student inputs, and if the answer is "we don't," does that commitment extend contractually to every subprocessor, including the foundation-model provider behind the product?
• Is student data used for anything beyond the immediate educational task, such as targeted advertising or cross-product analytics? Under COPPA, that kind of secondary use requires separate, standalone consent as of the FTC's 2025 amendments (FTC, 2025).

A purpose that isn't written into the contract isn't actually limited; it's just currently true.

Stage 4: Retention

"As long as necessary" stopped being an acceptable retention answer once the FTC's 2025 COPPA amendments took effect, and the same specificity standard is worth applying to every AI tool, not just ones covered by COPPA. A retention answer worth accepting names an actual window.

The written policy has to exist, not just the practice. Ask for the document itself, not a summary sentence from a sales page.

Stage 5: Third-Party Sharing

Every AI vendor sits at the front of a chain, and the district's real exposure often lives further down that chain than the contract signed at the top of it. A no-training promise from the vendor a district contracted with means little if it doesn't extend to the model provider actually processing the input. This stage matters most for AI tutoring tools where a student converses with a model directly, since more of the conversation itself becomes data that has to be tracked through the chain; SchoolAI vs Khanmigo: Which Is Better for Teachers? compares how two widely used platforms in that category are built.

The scale of how many of these relationships already run through standardized paperwork is worth knowing. The Student Data Privacy Consortium, a special interest group of the Access 4 Learning (A4L) Community, reports that its National Data Privacy Agreement template has been executed more than 275,000 times by districts and vendors since 2016, with its public resource registry now hosting over 130,000 signed agreements between more than 12,000 school systems and 6,674 education technology providers (A4L Community, 2025). That volume exists because ad hoc, vendor-by-vendor contract negotiation doesn't scale to the number of tools a typical district now touches.

Before accepting a vendor's sharing practices, confirm in writing:

1. Every named subprocessor, including the AI model provider.
2. Whether any subprocessor is authorized to use the data for its own purposes beyond fulfilling the contract.
3. Whether the district is notified before a new subprocessor is added, not after.

Stage 6: Deletion

A retention policy without a working deletion mechanism is a promise on paper, not a practice. This stage confirms the data actually disappears when it's supposed to, and that a district can verify it.

• On request: can a parent or eligible student request deletion of a specific record, and does the vendor confirm, not just acknowledge, when it's complete?
• On withdrawal: does a student leaving the district trigger automatic deletion, or does someone have to remember to request it?
• On graduation: is there a defined deletion or archival policy for records tied to students who've completed the program entirely?

A vendor that can describe its retention policy in detail but can't answer "how do we verify deletion actually happened" has a Stage 6 gap, even if Stages 1 through 5 all passed cleanly.

Documenting the Checklist So It Survives an Audit

A completed lifecycle checklist is only useful later if someone can find it later. A review run informally over email, with answers scattered across a sales conversation and a couple of PDF attachments, doesn't hold up the same way a single, dated, shared record does.

A durable record for each tool should capture:

• The date each stage was reviewed, and by whom, so a re-verification later has a baseline to compare against.
• The vendor's written answer for each of the six stages, quoted or attached directly, not paraphrased from memory.
• Any gap identified and how it was resolved, since a tool approved with a caveat ("retention window pending written confirmation") needs that caveat tracked until it's actually closed.
• The review date for the next check-in, tied to Stage 6's re-verification rather than left open-ended.

This matters most in the moment a district least wants to be improvising: a parent inquiry about what happened to their child's data, a state audit, or a new vendor's onboarding that surfaces a gap in an existing tool nobody had revisited in over a year. A dated record turns "we're fairly sure we checked that" into a specific, defensible answer.

A Model Workflow: Running the Checklist on One Tool

Say you're a Grade 7 math department chair evaluating an AI practice-problem generator that creates individualized problem sets and gives students a login to track their own progress over time. Before it reaches a full grade level, walk it through all six stages in sequence, not just the ones that feel most urgent.

• Collection: the tool captures a student ID, grade level, and a running log of answered problems, no name or contact information required.
• Minimization: confirm the running log is necessary for the adaptive-difficulty feature to work, rather than collected as a byproduct nobody scoped intentionally.
• Use limitation: confirm in writing that the answer log isn't used to train the vendor's model or shared with any analytics partner.
• Retention: get a specific window, end of school year, for how long the answer log persists after a student stops using the tool.
• Third-party sharing: name the subprocessors, including whichever AI provider powers the adaptive difficulty engine.
• Deletion: confirm what happens to a student's login and answer history if a parent requests removal mid-year.

Notice that a tool can pass Stages 1 through 3 cleanly and still fail at Stage 4 or 6. Treat all six as one gate a tool has to clear completely, not six independent checks where a tool only needs to pass most of them.

Where State Law Extends the Federal Floor

FERPA and COPPA set a federal minimum; more than a dozen states layer additional student-data-privacy statutes on top, and several of them speak directly to the lifecycle stages above. California's Student Online Personal Information Protection Act (SOPIPA, 2014) restricts operators from using student data for targeted advertising and from building non-educational profiles on students, reaching further into Stage 3's use-limitation question than federal law alone does. Illinois's Student Online Personal Protection Act (SOPPA, 2021) adds specific deletion-on-request obligations that sharpen Stage 6 beyond what COPPA requires outside the under-13 population.

A tool that clears every item on this checklist against FERPA and COPPA can still fall short of a specific state's statute. Confirming which state-specific rules apply is itself a checklist item, not an afterthought to run only if time allows.

New York's Education Law § 2-d adds a third example worth knowing even outside the state, because several other states have modeled newer legislation on it. Under Part 121 of the Commissioner's Regulations, effective January 2020, New York districts must publish a Parents' Bill of Rights for Data Privacy and Security, bar the sale of personally identifiable student information for any commercial purpose, align security practices with the NIST Cybersecurity Framework, and designate a Data Protection Officer responsible for the district's compliance (New York State Education Department, 2020). That kind of state-specific structural requirement, a named responsible officer, sits outside anything FERPA or COPPA mandates at the federal level.

Treat this table as a starting reference, not a complete map. A district operating in any state should confirm its own statute against all six lifecycle stages directly, since state legislatures continue to add to this list most years.

Related Reading

• AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
• Diffit and Student Data Privacy: What Teachers Should Know
• How Schools Can Use AI Without Violating Data Security
• COPPA and AI in Education: A Guide for Administrators
• Kahoot and Student Data Privacy: What Teachers Should Know
• SchoolAI vs Khanmigo: Which Is Better for Teachers?