Every new app that touches your district touches your risk profile. The vendor demo shows the features; it never shows the data flow. This checklist is the one we'd want handed to us if we were still sitting in the district CTO chair — the questions that separate vendors who engineered for student privacy from vendors who bolted a privacy page onto a marketing site.

Start with the DPA, not the demo

A Data Privacy Agreement (DPA) is the fastest vendor filter that exists:

  • Ask for the signed DPA before the pilot, not after. A vendor who hesitates on a DPA is telling you their data practices can't survive one.
  • Use your state's standard where one exists. Texas districts can leverage the TX-NDPA (the Texas Student Privacy Alliance's standard agreement); a vendor already on file with your regional ESC or the SDPC registry has done this dance before.
  • Check the exhibit, not just the signature. The DPA's data elements exhibit should list *exactly* what the product collects. If the exhibit says "directory information" and the product asks for birth dates and photos, stop.

The FERPA questions that actually differentiate vendors

Everyone claims FERPA compliance. These questions find out who engineered for it:

  1. What student data do you collect, and why does the product need each element? The best answer is a short list. A great answer is "none — the workflow doesn't require student records." Data you never collect is data you never breach.
  2. Who is the school official here? Under FERPA's school-official exception, the vendor must be under your direct control regarding data use. The DPA should say so explicitly.
  3. What happens at contract end? Deletion timelines, certification of destruction, and your right to a full export — in writing.
  4. Is data ever used for product improvement, analytics, or AI training? The correct answer for student data is no, and it should be contractual, not verbal.

Data residency and subprocessors

  • U.S.-only data residency should be stated plainly: where data is stored, where it's processed, and where backups live. "We use the cloud" is not an answer; "US-region only, including backups" is.
  • Get the subprocessor list. Your vendor's privacy posture is only as strong as the vendors *they* use. Hosting, email, analytics, support tooling — each is a place student data can leak.
  • Breach notification terms. Hours-or-days notice with a named contact, not "as required by law."

Payments: don't let card data anywhere near the district

If the product takes money — tickets, fees, spirit stores — the payment architecture matters more than the feature list:

  • Card data should never touch the vendor's servers or yours. The modern standard is a PCI DSS Level 1 processor like Stripe, where card entry happens in the processor's own hosted fields and the district receives payouts directly.
  • Payouts should land in the district's account, not pool in the vendor's. Ask who holds the money between sale and settlement — the answer reveals both risk and float games.
  • Refund and chargeback handling should be district-controlled, with a real audit trail for your business office.

This is exactly how we built Its1Ticket: Stripe-processed payments, direct district payouts, and no card data in our systems — because the safest data posture is not holding the data at all.

The one-page vendor scorecard

Before any pilot, get written answers to these ten:

  1. Will you sign our DPA (or the TX-NDPA) before the pilot?
  2. Exact list of data elements collected — student, staff, and parent?
  3. Where is data stored and processed, including backups? U.S.-only?
  4. Full subprocessor list?
  5. Is any district data used for analytics, ads, or model training?
  6. Breach notification window and named security contact?
  7. Deletion and export terms at offboarding?
  8. Who processes payments, and do payouts go directly to the district?
  9. SSO support and role-based access for district staff?
  10. What's the contract term — and can we leave without penalty?

A vendor who answers all ten in plain language in one email is a vendor whose engineering probably matches their marketing. We publish our own answers to these questions for every product we ship — ask us for them, or read more about how we build FERPA-first software.