What is the best way to evaluate edtech vendors against your district's data privacy policies in 2027?

The scenario every district technology director recognizes

It is late February. A middle school math department has been piloting an adaptive practice platform since October, running it on a free tier a teacher signed up for with a school email address. The pilot went well. Test scores moved. The principal wants it district-wide for next year, and the budget window closes in six weeks. Someone finally loops in the technology director, who pulls up the vendor's privacy policy and finds three sentences that should have stopped the pilot on day one: the platform reserves the right to use "de-identified usage data" for product development, lists no subprocessors, and points to a generic terms-of-service page that can be amended "at any time without notice."

Nobody did anything malicious here. This is simply what happens when the procurement path and the classroom adoption path are different paths. Teachers find tools that work. Free tiers require no purchase order, so no purchase order triggers a review. By the time the tool reaches a district contract, it already has eight months of student work product, a roster of student names and email addresses, and an entrenched constituency of teachers who will be furious if you kill it.

The evaluation problem is therefore not really a technical problem. It is a sequencing problem. The best way to evaluate edtech vendors against your district's data privacy policies is to build a repeatable, documented review that runs *before* a tool touches student data, that produces the same artifacts every time regardless of who runs it, and that a school board member or a parent could read and understand. Everything below is in service of that.

Three structural realities shape how this works in practice. First, the legal floor is federal: FERPA governs education records and the school official exception that lets vendors act on your behalf, COPPA governs personal information collected from children under 13, and PPRA governs surveys touching protected categories. Second, the operative floor in most districts is state law, and a large majority of states have passed student-privacy statutes since 2014 — many modeled on the pattern set by California's SOPIPA, which prohibits targeted advertising to students, prohibits building non-educational profiles, and prohibits selling student information. Third, the actual enforceable floor is your contract. Federal and state law set boundaries; the data privacy agreement is what you can point to when a vendor's behavior drifts.

A good evaluation makes all three layers explicit and checks the vendor against each one. A bad evaluation reads the vendor's public privacy policy, sees the word "FERPA," and approves.

How the review mechanism actually works

The mechanism is a gate with a fixed sequence of stages, each producing an artifact, each with an owner and a decision. The reason to formalize it is that informal review collapses under time pressure — and time pressure is the normal state of school procurement.

Stage one: intake and data classification. Every request, whether from a teacher, a curriculum director, or a vendor cold-call, enters through one form. The form asks what problem the tool solves, who will use it, what grade levels, and — the pivotal question — what data elements it will receive. Classify the answer into tiers. Tier zero is no personal data: an anonymous reference site, a video library with no accounts. Tier one is directory-type identifiers only: name, teacher assignment, grade level. Tier two is instructional data tied to an identified student: assignment submissions, assessment scores, reading level, time-on-task. Tier three is sensitive: IEP and special education records, health information, behavioral or disciplinary records, free-and-reduced-lunch status, English learner status, biometric or precise location data, or anything captured by camera or microphone.

The tier determines the depth of review. Tier zero can clear in a day with a lightweight check. Tier three should require legal counsel review, a documented data protection impact assessment, and explicit sign-off from the superintendent's cabinet. Districts that skip tiering end up applying either too much process to trivial tools — which is how you get shadow IT — or too little process to the ones that matter.

Stage two: legal and contractual review. This is where you evaluate the vendor's paper against your policies. You are reading for specific clauses, not general vibes, and the section below on numbers gets into what "specific" means.

Stage three: security review. Request the vendor's security documentation. What you are looking for is evidence of an independent assessment: a SOC 2 Type II report under NDA, an ISO/IEC 27001 certificate with the statement of applicability, or for larger platforms, participation in a recognized education-sector assessment program. Absence of any third-party audit is not automatically disqualifying for a small vendor, but it shifts weight onto the contract and onto your own testing. Verify encryption in transit and at rest, multi-factor authentication for administrative accounts, single sign-on support, role-based access controls, logging and log retention, and whether the vendor runs its own penetration testing.

Stage four: instructional and accessibility review. Privacy review that ignores accessibility just moves the compliance failure. Request a current accessibility conformance report — the VPAT format built on WCAG — and read the "partially supports" rows, which is where the real gaps hide.

Stage five: decision and documentation. Approve, approve with conditions, or decline, with the reasoning written down. Publish the approved list somewhere teachers can actually find it, because an approved-tools list nobody can search generates exactly the shadow adoption the process was built to prevent.

The loop back from approval to re-review is the part districts most often skip. A vendor approved in 2025 may have been acquired, changed its subprocessors, added an AI feature that trains on submissions, or quietly amended its terms. Approval is a snapshot; the policy question is continuous.

The clauses to demand and the numbers to hold vendors to

Vague requirements produce vague contracts. Here is what to require in writing, with the concrete parameters that make each clause enforceable.

Data ownership. The agreement must state plainly that the district — or the parent and student, as applicable under law — retains ownership of all student data, and that the vendor is a processor acting under district direction as a school official under the FERPA exception. If the contract is silent on ownership, assume the vendor's default terms control, and those default terms rarely favor you.

Permitted use, stated narrowly. The vendor may use student data only to provide the contracted service. Explicitly prohibit: targeted advertising to students or families, creating profiles for non-educational purposes, selling or renting student information, and — this is the clause that matters most in 2027 — using district student data to train, fine-tune, or improve machine learning models beyond the district's own instance. Many vendors will accept a carve-out for aggregate service metrics; that is usually reasonable. Be precise about what "de-identified" means and require that de-identification follow a documented standard, that re-identification be contractually prohibited for the vendor and any recipient, and that the district be notified before de-identified data is shared with third parties.

Subprocessors. Require a complete current list at signing, naming each subprocessor, what it does, and where it processes data. Require advance written notice — 30 days is a reasonable ask, though many vendors negotiate to 14 or offer a subscribe-to-updates page — before adding or replacing one, with a right to object and, if unresolved, to terminate without penalty. A vendor that cannot produce a subprocessor list is telling you it does not know where your data goes.

Breach notification. Set an outer bound in hours, not "promptly." Many state student-privacy statutes and district agreements land in the 24-to-72-hour range from the vendor's discovery of an incident. Specify what the notice must contain: what happened, when, which data elements, how many district records, containment steps, and remediation plan. Specify who bears notification costs — vendor-borne notification costs are standard in negotiated agreements and are worth pushing for. Require cooperation with the district's own investigation and with law enforcement.

Retention and deletion. Two separate obligations. Ongoing retention: define how long the vendor keeps data during the term and require deletion of records no longer needed. Termination: require return or certified destruction within a fixed window — 30, 60, or 90 days is the common range — including backups, with a written certificate of destruction naming the systems purged. Ask specifically about backup rotation, since a vendor may delete production data promptly while backups persist for months. Get the backup expiry period in writing rather than treating it as an implementation detail.

Parent and student rights. The agreement must let the district honor FERPA inspection and amendment requests, which means the vendor has to be able to produce, correct, and delete an individual student's records on request within a defined turnaround. FERPA gives districts 45 days to respond to an inspection request; a vendor turnaround materially shorter than that — 10 to 15 business days — is what makes the district's obligation achievable.

Amendment control. Prohibit unilateral changes to material privacy terms. The signed agreement must supersede any click-through terms of service, and the vendor must not be able to modify by posting to a webpage. Include an explicit order-of-precedence clause naming the data privacy agreement as controlling over the ToS, the order form, and any incorporated URLs.

Audit and evidence. Annual delivery of the current SOC 2 Type II or equivalent, notice of any material adverse finding, and — for tier three data — the right to request evidence of controls or to conduct a limited assessment.

Insurance and liability. Cyber liability coverage sized to your exposure. Districts commonly require one to five million dollars depending on record volume and data sensitivity. Push to carve data breach liability out of the general liability cap, since a standard cap set at twelve months of fees is meaningless against the real cost of notifying tens of thousands of families.

Timeline planning. Budget realistically. A tier-zero tool can clear in one to three business days. A tier-one or tier-two tool with a vendor that already signs your state's standard agreement clears in one to three weeks. A tier-three tool with a vendor that insists on its own paper takes six to twelve weeks and sometimes a full quarter, because it requires counsel on both sides. Districts that promise principals a two-week turnaround on everything either break the promise or break the review. Publish the real timelines and hold the line.

Trade-offs: standard agreements, one-off contracts, and saying no

There is no evaluation approach that is fast, thorough, and universally accepted. You are choosing which constraint to relax.

Joining a state or regional student data privacy consortium. The dominant model is a shared standard agreement — the National Data Privacy Agreement pattern, adopted by state alliances across much of the country — where vendors sign once and every member district can attach an exhibit. The advantage is enormous: the negotiation cost collapses to near zero for any vendor already in the registry, terms are consistent across your portfolio, and small districts get the leverage of large ones. The trade-off is that the standard terms are a compromise. If your board policy is stricter than the consortium baseline on some point — say, an outright prohibition on any model training rather than an opt-out — you still need a rider. Also, consortium membership does not remove your obligation to evaluate; it removes the drafting work, not the judgment.

Negotiating district-specific agreements. You get exactly the terms your policies require and can encode local board language directly. The cost is time and legal spend, and leverage is a function of district size. A district of 40,000 students gets returned redlines; a district of 900 students often gets a form response saying the vendor does not modify its standard terms. If you are small, the consortium path is not merely more convenient, it is the only way to get terms you could not otherwise command.

Accepting the vendor's paper as-is. Sometimes defensible for tier-zero tools with no personal data. Rarely defensible above that. If you must, document what you accepted and why, and set a shorter re-review interval.

Declining and finding an alternative. Underused. The single strongest evaluation tool is the credible willingness to walk. This requires that you have an alternative and that instructional leadership backs you, which is why privacy review should sit inside curriculum adoption rather than beside it. When two products serve the same instructional goal, privacy posture is a legitimate tiebreaker — and telling vendors that during the RFP changes what they bring you.

Mitigating rather than blocking. Sometimes the right answer is to narrow the data instead of rejecting the tool. Send fewer fields. Use pseudonymous student identifiers instead of names. Roster through a standards-based integration that shares only what the tool needs rather than granting a full directory sync. Disable a feature. Restrict to a grade band. This preserves instructional value while shrinking exposure, and it converts a binary fight into a negotiation about scope.

Pitfalls that survive even a good process

Reading the privacy policy instead of the contract. A public privacy policy describes what the vendor does today and can change tomorrow. It is evidence, not obligation. Evaluate the contract, and require the contract to control over anything posted at a URL.

Free tiers. The most common breach of district policy is not a hacked database; it is a teacher clicking "Sign in with Google" on a free tool and rostering thirty students. Free means the district signed nothing, so no data privacy agreement exists, and the vendor's consumer terms apply to children's records. Fix this structurally: restrict third-party OAuth app access in your identity provider to an allowlist, so unapproved tools cannot silently receive rosters. That single control does more than any amount of training.

Assuming a signature ends the work. Vendors get acquired, and acquisition is when data-use terms most often change. Watch for change-of-control events and require notice with a right to terminate. Also monitor product changes: a stable vendor shipping an AI tutoring feature in a routine release may begin sending student prompts to a model provider that was never on your subprocessor list.

Treating "de-identified" as a magic word. De-identification is a spectrum, not a state. In small districts and small subgroups, a handful of quasi-identifiers — school, grade, course, and a date — can re-identify a student trivially. Require a documented method, a contractual ban on re-identification that binds downstream recipients, and skepticism about any de-identified dataset drawn from small cells.

Ignoring where data physically lives. Ask where data is stored and processed, including by subprocessors, and whether support staff outside the country can access production data. Some state statutes and many board policies constrain this. Even where law is silent, knowing your data map is a prerequisite for answering a parent's question honestly.

Letting the pilot become the decision. The scenario at the top of this page is the canonical failure. Require a time-boxed pilot agreement with the same privacy terms as a full contract, a defined end date, and mandatory deletion at the end if the tool is not adopted. Pilots without deletion clauses are permanent data transfers with optimistic labels.

No inventory. You cannot evaluate a portfolio you cannot list. Build and maintain a register of every approved tool: vendor, data elements, tier, agreement date and expiration, subprocessors, security documentation date, deletion terms, and internal owner. Reconcile it annually against actual OAuth grants and actual spend, because the gap between the approved list and reality is where the risk concentrates.

Silence toward families. Most state statutes and good practice both point to publishing the list of approved tools and what data each receives. A parent who can look this up rarely files a complaint. A parent who cannot, sometimes does — and a public records request will produce the list anyway, just on someone else's timeline and without your framing.

One person holding the whole process. If evaluation lives entirely in one technology director's head, it stops when they take a new job. Write the rubric down, use the same scoring template every time, store artifacts in a shared location, and make sure at least two people can run a review start to finish.

Related questions

Does FERPA by itself let a vendor receive student data?

Only under the school official exception, and only if the vendor performs a service the district would otherwise perform, is under the district's direct control over data use and maintenance, and does not redisclose. Those conditions have to be written into the contract to hold.

What is the difference between a data privacy agreement and a data processing addendum?

Functionally similar documents from different traditions. Education-sector DPAs are built around FERPA, COPPA, and state student-privacy statutes; DPAs in the GDPR sense are built around controller-processor obligations. Districts serving international families sometimes need both sets of terms.

Should teachers be allowed to adopt free tools directly?

Not for anything receiving student data. The practical control is technical, not procedural: allowlist OAuth applications in your identity provider and publish a searchable approved catalog so the easy path is also the compliant one.

How often should approved vendors be re-reviewed?

Annually at minimum, plus event-triggered review on acquisition, material terms changes, new subprocessors, a reported breach, or any new AI or analytics feature. Tier three tools warrant tighter monitoring than an annual cycle.

What if a vendor refuses to sign anything but its own terms?

Treat refusal as data. Narrow the data scope, seek an alternative, or accept and document the risk with executive sign-off and a short re-review interval. Never approve an exception silently at the staff level.

FAQ

Who should own edtech privacy evaluation in a district?

A named cross-functional group with a single accountable owner, usually the technology director or a designated data protection officer. Membership should include curriculum, special education, legal counsel or outside counsel on call, and a building-level administrator. The owner runs the process and signs the decision; the group provides the judgment the owner cannot supply alone. What matters more than the org chart is that the role is named in board policy so it survives staff turnover.

How do we evaluate AI features inside existing tools?

Treat a new AI feature as a new evaluation, not a version update. Ask which model provider processes the data, whether that provider is on the subprocessor list, whether prompts and student submissions are retained and for how long, whether inputs train models, and whether outputs are logged. Require the answers in writing and add them to the agreement by amendment. If the vendor cannot say where student prompts go, that is a complete answer.

What does a realistic evaluation rubric look like?

A scored checklist with weighted categories — contractual terms, security posture, data minimization, accessibility, and vendor viability — where each line item is objectively verifiable rather than impressionistic. "Subprocessor list provided and current" is checkable; "vendor seems trustworthy" is not. Set a minimum passing score and define which line items are automatic disqualifiers regardless of total, such as a refusal to prohibit sale of student data.

Can we use a national vendor registry instead of doing our own review?

Registries and consortium databases are a strong accelerator and can cut weeks off review, but they answer whether a vendor signed a standard agreement — not whether that agreement satisfies your specific board policies, your state statute, or the particular data elements you plan to send. Use the registry to skip the drafting, then run your own gap check against local requirements.

What should we do about tools already in use that never got reviewed?

Inventory first, then triage by data sensitivity and user count rather than trying to review everything at once. Start with tools touching tier three data or serving the most students. For each, either obtain a signed agreement, narrow the data, or sunset the tool with a deletion certificate. Communicate the sunset timeline to teachers well ahead of it, since the process fails politically far more often than technically.

How do we handle vendors whose subprocessors change frequently?

Accept the reality of cloud infrastructure but require notice and a documented objection path. Ask for a subscribe-able subprocessor page rather than emailed notices, and assign someone to monitor it. If a vendor changes subprocessors constantly and cannot notify reliably, weight that against them in scoring and reflect it in a shorter re-review interval.

Sources

• https://studentprivacy.ed.gov/ — U.S. Department of Education Student Privacy Policy Office
• https://www.ecfr.gov/current/title-34/subtitle-A/part-99 — FERPA regulations, 34 CFR Part 99
• https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa — FTC COPPA Rule
• https://privacy.a4l.org/national-dpa/ — Access 4 Learning Student Data Privacy Consortium, National DPA
• https://www.nist.gov/cyberframework — NIST Cybersecurity Framework
• https://csrc.nist.gov/pubs/sp/800/171/r3/final — NIST SP 800-171, protecting controlled unclassified information
• https://www.w3.org/WAI/standards-guidelines/wcag/ — W3C Web Content Accessibility Guidelines
• https://www.cisecurity.org/controls — CIS Critical Security Controls
• https://iapp.org/ — International Association of Privacy Professionals
• https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2 — AICPA SOC 2 reporting

Related on PULSE

• How to build a vendor security questionnaire that suppliers will actually complete
• What belongs in a data processing addendum for a SaaS contract
• How to run an annual vendor re-review without stalling the business
• Building a software inventory when shadow IT already exists
• How to evaluate an AI feature added to a tool you already bought
• What to require in a breach notification clause