A FERPA Compliance Checklist for AI Tools in Schools
An IT director staring down a stack of AI vendor RFP responses needs more than a pass/fail list of features. FERPA compliance gets built into the procurement paperwork itself, before a contract is signed, through specific RFP disclosure requirements, a red-flag list for reviewing the DPA that comes back, and a documented audit trail that survives the reviewer who wrote it moving to a different job. This checklist is built for that stage of the process, not the classroom pilot stage.
Quick Answer: A FERPA-ready AI procurement process requires three artifacts before a contract is signed: an RFP that mandates specific data-practice disclosures, a signed Data Processing Agreement (DPA) reviewed against a known red-flag list, and a documented audit file an outside reviewer could inspect without asking the original evaluator a single follow-up question. Below is the checklist built for the people who run that process: IT directors, procurement officers, and district student-data-privacy leads.
This is the audit-prep companion to EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026). It is deliberately narrower than our teacher-facing vendor checklist, which walks a classroom teacher through eight questions to ask before trying a tool. This one is written for the procurement side of the table: the RFP language, the contract review, and the paper trail an auditor or school board member would actually ask to see.
Who This Checklist Is For, and How It Differs From a Teacher's Checklist
This checklist assumes you are running a formal procurement process, not evaluating a single classroom tool informally. A teacher deciding whether to try an AI worksheet generator needs a short list of yes/no questions. An IT director issuing an RFP for a district-wide AI writing assistant needs scoring criteria, contract-language standards, and a documentation system that outlasts any one person's memory of the review.
The two checklists overlap on substance, training defaults, retention terms, admin controls, but differ in form. A teacher's checklist produces a go/no-go decision on one tool. A procurement checklist produces an auditable record covering every vendor a district has ever formally reviewed, which is what actually gets requested when a school board member or a state auditor asks "how do we know this was vetted."
That difference in form matters more than it sounds. A teacher's checklist can live in a shared document a department revisits informally. A procurement record has to answer a harder question months or years later: not "did we think about this," but "can you show me exactly what the vendor promised, who reviewed it, and when." If the answer requires digging through an old email thread, the checklist has already failed its actual job.
What to Put in the RFP Before a Vendor Ever Responds
The strongest procurement leverage a district has is written into the RFP itself, before any vendor submits a proposal. Waiting until contract negotiation to raise FERPA requirements means starting from a weaker position; a vendor that already committed to the terms during bidding has less room to walk them back later.
Mandatory Disclosure Requirements
Require every bidder to answer these in writing as part of the proposal, not as a follow-up after selection:
- Whether the product trains on district data by default, and whether that default can be turned off at the account level.
- The named foundation model or models powering the product, and whether the vendor's no-training commitment extends contractually to that provider.
- A specific, numeric data-retention window, not a phrase like "as long as necessary."
- Whether individual student accounts are required, or whether a teacher-mediated workflow is available.
- A complete list of subprocessors that will touch district data, updated with notice of any change.
- Confirmation that a signed DPA, not a public terms-of-service page, will be available before rollout.
These six were chosen deliberately, not as an exhaustive privacy audit but as the smallest set of questions that maps directly onto FERPA's four-part school-official test and COPPA's under-13 consent pathway at once. A vendor that answers all six in writing has, in practice, already demonstrated the direct control, purpose limitation, and no-redisclosure conditions FERPA requires, without the district needing a separate legal memo to prove it.
Scoring Criteria Tied to FERPA's Four-Part Test
Score each proposal against FERPA's "school official" exception (34 CFR § 99.31(a)(1)) directly, rather than treating privacy as a generic bonus category. CoSN's 2026 State of EdTech Leadership Report, drawing on 607 K-12 leaders across 44 states, found that 56% of districts now require vendors to provide specific product-safety information before adoption, up from a much smaller share in prior years (CoSN, 2026).
Far fewer of those same districts tie that safety information to a formal scoring rubric once it arrives; the disclosure gets collected and then sits unused in the decision itself. Building the four-part test directly into the RFP's scoring sheet, rather than treating it as background reading, closes that specific gap.
Building the RFP Scoring Rubric
Turning the six mandatory disclosure questions into a scored rubric, rather than a yes/no checklist, is what makes the RFP defensible later. A rubric shows exactly how a vendor won or lost points on privacy grounds, which matters if a losing bidder ever questions the award, and it matters just as much for showing a board that privacy wasn't an afterthought.
A workable rubric assigns each disclosure item a point value and a clear standard for full, partial, or no credit:
| Disclosure item | Full credit | Partial credit | No credit |
|---|---|---|---|
| Training default | Off by default, contractually confirmed | Off by default, stated but not in the DPA | On by default, or unanswered |
| Named model provider | Named specifically, no-training commitment extends to it | Named, but training commitment doesn't clearly extend | Not named |
| Retention window | Specific number of days/months, with deletion trigger | A range given, without a deletion trigger | "As long as necessary" or unanswered |
| Account structure | Teacher-mediated option available and described | Available but not the default | Individual student accounts only |
| Subprocessor list | Complete list provided, with change-notice terms | Partial list, or no change-notice terms | Refused or unanswered |
| DPA availability | Signed DPA available before rollout | DPA available, but only after selection | Terms-of-service only, no DPA |
Weight training default, account structure, and DPA availability the heaviest of the six; a strong answer on subprocessor disclosure doesn't offset a vendor unwilling to sign a contract at all. A vendor scoring "no credit" on DPA availability should be disqualified outright, regardless of its total score on the other five items.
The DPA Red-Flag List: Contract Language That Should Stop a Purchase
A DPA that comes back from legal review needs to be read against a specific list of red flags, not just skimmed for reassuring language. The table below separates language that satisfies FERPA's requirements from language that only sounds like it does.
| Contract element | Acceptable language | Red flag |
|---|---|---|
| Data use scope | Data used solely to provide the contracted service | "Data may be used to improve our products and services" with no further definition |
| Training default | Training excluded by default for institutional accounts, or explicit opt-in only | Silent on training, or training bundled into a broad "product improvement" clause |
| Subprocessor disclosure | Named list of subprocessors, with notice required before adding new ones | No subprocessor list, or a reference to "our partners" without naming them |
| Retention | A specific window (30 days, 12 months, contract term) with defined deletion triggers | "Data retained as long as reasonably necessary," undefined |
| Redisclosure | Explicit bar on sharing with unrelated third parties | Vague or missing redisclosure language entirely |
| Breach notification | A defined notification window, commonly 24 to 72 hours in comparable enterprise contracts | No mention of breach notification timelines |
| Termination data handling | Data deleted or returned within a stated period after contract end | No provision for what happens to data after the contract ends |
Any single red flag in this table is a reason to send the DPA back for revision before signature, not a minor point to negotiate away quietly during onboarding.
What to Document for Audit-Readiness
A vendor review that lives only in one reviewer's email inbox is not an audit trail. Build a vendor file for every AI tool the district formally adopts, and keep it current, not just complete at the moment of signature.
The Vendor File
Each approved vendor's file should contain, at minimum:
- The signed DPA itself, not a summary of it.
- The RFP responses to the six mandatory disclosure questions above.
- A record of which scoring criteria the vendor met and which it didn't.
- The name of the internal reviewer and the date of review.
- Confirmation of the account structure chosen (teacher-mediated or student-direct) and why.
A vendor like EduGenius, built around teacher-managed class profiles rather than open student chat accounts, illustrates the kind of specific, checkable answer a vendor file should capture: not just "student data is protected," but exactly which data touches which system, and under whose account.
A file is complete when a reviewer who wasn't in the room can reconstruct the decision from the documents alone. That's a higher bar than "we have the DPA on file." If a school board member asked why a particular vendor was approved for Grade 3 use with teacher-mediated accounts rather than individual logins, the file should answer that without anyone needing to remember the meeting where it was decided.
Layering State Law Into the RFP Template
Federal law is the floor for an RFP template, not the ceiling. More than a dozen states have their own student-data-privacy statutes stacked on top of FERPA and COPPA, including California's Student Online Personal Information Protection Act (SOPIPA, 2014) and Illinois's Student Online Personal Protection Act (SOPPA, 2021), both of which restrict vendor data use more tightly than federal law alone.
Build a state-law addendum into the RFP template rather than treating it as a one-off legal review each time. If a vendor's standard DPA satisfies FERPA and COPPA but hasn't been checked against your state's specific statute, that gap belongs in the vendor file too, flagged for legal review before the contract is finalized, not discovered afterward during an unrelated audit.
The Annual Re-Verification Record
Vendor terms change, and a file that stops updating after signature drifts out of date within a year. The Future of Privacy Forum notes that state lawmakers accelerated AI-specific privacy regulation sharply in 2025, on top of more than 128 existing state student-privacy statutes districts already had to track (FPF, 2025). A district's re-verification record should show, for each vendor, the date of the last check and any changes found, not just the date of original approval.
A Procurement Scenario: Vetting a New AI Writing Tool
Say your district is running an RFP for an AI-assisted writing feedback tool for Grades 6 through 8. Three vendors respond. One answers all six mandatory disclosure questions in writing, including naming its underlying model provider and confirming a 12-month retention window. The second answers four of six, leaving subprocessor disclosure and breach notification blank. The third responds only with a link to its public terms of service.
Running the red-flag table against each DPA narrows the field fast. The third vendor is disqualified outright: no DPA means no path through FERPA's school-official exception, regardless of how the product performs in a demo. The second vendor gets a follow-up request for the two missing disclosures before scoring continues.
Only the first vendor's file is complete enough to close without additional back-and-forth, and that completeness, not the demo, is what the scoring rubric rewards. When the district's student-data-privacy officer signs off, the vendor file already contains the RFP responses, the scored rubric, the signed DPA, and the account-structure decision, teacher-mediated, for this grade band, so a future reviewer never has to reconstruct the reasoning from scratch.
Pro Tips for IT Directors Running Multiple Vendor Reviews
- Standardize the six disclosure questions across every RFP, not just AI-specific ones, so the review process doesn't have to be reinvented for each new procurement cycle.
- Assign one named owner per vendor file. Without a named person, the paper trail tends to disappear when that staff member changes roles.
- Ask for specific pricing structures in writing, not verbal estimates. A vendor that publishes exact figures, the way EduGenius states its Starter tier at $7.99 per month for 500 credits and its Professional tier at $15.99 per month for 1,000 credits, is easier to compare and budget against than one that only quotes custom pricing after a sales call.
- Route every red flag through the same escalation path. A red flag caught by one reviewer but never escalated is functionally the same as never catching it.
- Keep the vendor file separate from the pilot file. A tool that performed well in an informal classroom pilot still needs its own procurement-stage documentation before district-wide rollout.
- Build a state-law addendum into the RFP template once, rather than re-researching your state's specific student-privacy statute for every new procurement cycle.
What to Avoid: Four Procurement Mistakes
- Scoring privacy as a soft bonus category instead of a scored requirement. If FERPA's four-part test isn't built into the rubric, it competes with feature checklists for attention and usually loses.
- Accepting a verbal assurance in place of a written disclosure. A sales call promise that "we don't really use the data for anything else" has no evidentiary value once the contract is signed.
- Letting one pilot's success skip the formal RFP process for the district-wide rollout. A single classroom's positive experience is not a substitute for the vendor file a full deployment requires.
- Filing the DPA and forgetting the re-verification date. A red-flag-free contract at signing can still drift out of compliance as the vendor's own terms and subprocessors change.
- Assuming a satisfied federal test means the whole procurement is done. A vendor can clear FERPA and COPPA cleanly and still fall short of a stricter state statute like SOPIPA or SOPPA if nobody checked for it.
Key Takeaways
- Procurement-stage FERPA compliance is a paper trail, not a one-time judgment call. The RFP, the DPA, and the vendor file together are what an auditor actually reviews.
- Build the six mandatory disclosure questions into every AI-related RFP: training defaults, named model provider, retention window, account structure, subprocessor list, and DPA availability.
- Score proposals against FERPA's four-part "school official" test directly (34 CFR § 99.31(a)(1)), rather than treating privacy as a generic bonus category.
- Use the red-flag table to review every DPA the same way, so contract review quality doesn't depend on which staff member happens to read it.
- A complete vendor file survives staff turnover; an email thread does not.
- This checklist is procurement-facing, distinct from a teacher's quick-start vendor checklist; both matter, but they answer different questions for different roles.
- Re-verification is not optional. More than 128 state student-privacy statutes, on top of federal law, mean a compliant contract today can need updating within a year (FPF, 2025).
Frequently Asked Questions
What's the difference between this checklist and a teacher's AI vendor checklist?
This checklist is built for the procurement stage, RFP language, contract scoring, and audit documentation, run by IT directors or district privacy officers. A teacher's checklist is a shorter, faster set of yes/no questions meant for evaluating a single classroom tool before an informal trial.
Does a district need a lawyer to review every AI vendor's DPA?
Not necessarily for every vendor, but any DPA missing items from the red-flag table above should go to legal or a designated student-data-privacy officer before signature. Routine renewals of an already-approved vendor's terms need less scrutiny than a first-time contract.
How often should a vendor file be updated after the contract is signed?
At minimum annually, and immediately after any vendor announcement about a change in data practices, subprocessors, or retention defaults. A file that stops updating at signature is functionally outdated within a year, given how often vendor terms shift.
Can a district use the same RFP template for every AI tool, regardless of subject or grade level?
The same six disclosure questions and red-flag review apply universally, but the account-structure decision, teacher-mediated versus student-direct, and the risk tier assigned should still reflect the specific tool and grade band, since a Grade 2 reading tool and a Grade 8 tutoring chatbot carry different exposure.
What happens if a vendor scores well on the rubric but a state auditor still flags the contract?
Pull the vendor file and check it against the specific concern raised; a well-documented file usually resolves the question quickly by showing exactly what was reviewed and when. If the gap is a state statute the RFP template didn't cover, add it to the template going forward so the same gap doesn't recur in the next procurement cycle.
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 FERPA
- SOC 2 and AI in Education: A Guide for Administrators
- FERPA-Compliant AI Tools for Teachers: A 2026 Checklist
- SchoolAI vs Khanmigo: Which Is Better for Teachers?