What district IT teams usually ask before approving a new vendor

Why vendor approval takes longer than it used to

A few years ago, a teacher could sign up for a new tool with a school email and start using it the next day. That era is over at most districts. Data privacy legislation, a wave of high-profile breaches involving student records, and clearer FERPA/COPPA enforcement have pushed most IT departments to require a formal review before any new vendor touches student data.

This is a good development. Students deserve protection. But it means teachers and administrators who want to bring in new curriculum tools need to understand what the review process is actually looking for - so they can prepare properly and help their vendor respond quickly.

Here is a practical breakdown of what district IT teams typically ask, based on conversations we have had with technology coordinators across several provinces and states.

1. Who holds the data and where is it stored?

This is always the first question, and "the cloud" is not an acceptable answer.

IT teams want to know: - The name of the primary cloud provider (AWS, GCP, Azure, etc.) - The region where data is stored (US-East, Canada-Central, EU-West, etc.) - Whether data ever transits through or is stored in a jurisdiction with different privacy standards than the district's home jurisdiction

For Canadian schools, data residency in Canada or the US is typically acceptable under PIPEDA and provincial equivalents, but storage in countries outside the Five Eyes or EU may trigger additional scrutiny.

What to prepare: Ask your vendor for their infrastructure overview document. It should name the cloud provider and the storage regions explicitly.

2. What data do you actually collect?

IT teams distinguish between data types. The categories they care most about:

Student PII (personally identifiable information): Name, email, date of birth, student ID number. Any combination of these that could identify a specific child.

Behavioural data: Login timestamps, page views, feature usage, lesson completion records. Technically not PII by itself, but still covered under FERPA if it can be linked back to an individual student record.

Content data: Anything a student types, uploads, or submits. This category gets the most scrutiny because it can contain sensitive personal disclosures.

Device and network data: IP addresses, browser fingerprints, device identifiers. Often collected incidentally by analytics tools.

A vendor who says "we only collect what we need" without specifying what that means is a yellow flag. A well-prepared vendor will hand you a data inventory table.

3. FERPA and COPPA compliance posture

In the US, FERPA governs educational records held by institutions and shared with vendors. COPPA governs data collection from children under 13. These overlap in school settings in ways that are not always obvious.

The key question IT will ask: "Are you acting as a school official under FERPA?"

This matters because FERPA allows schools to share student records with vendors without parental consent, but only when the vendor is under direct control of the school and uses the data only for the purpose specified. If a vendor uses student data for model training, advertising targeting, or product development, they fall outside the school official exception.

IT teams will also ask: - Do you require parental consent for students under 13, or do you rely on the school to manage that through the FERPA school official exception? - What is your process if a parent requests deletion of their child's records? - Have you ever received a COPPA complaint or enforcement action?

For Canadian schools: The equivalent framework is PIPEDA federally and provincial privacy acts (PIPA in BC and Alberta, PHIPA in Ontario, Law 25 in Quebec). The questions are structurally similar but the consent and notification requirements differ by province. Quebec's Law 25 is currently the most stringent, requiring explicit consent for profiling and mandatory 72-hour breach notification.

4. Subprocessors

Almost every SaaS product uses subprocessors - third-party services that handle part of the data pipeline. Common examples include email delivery services (Postmark, SendGrid), error monitoring (Sentry), analytics platforms (Amplitude, Mixpanel), and AI providers.

IT teams ask for a complete subprocessor list because each subprocessor represents an additional party with access to student data. If the primary vendor is FERPA compliant but a subprocessor is not, the whole chain fails.

What to look for in the subprocessor list: - Is the list current and dated? - Are all subprocessors operating in compliant jurisdictions? - Does the vendor notify customers before adding new subprocessors?

5. Data deletion and retention policy

Schools need to know what happens to student data when: - A student leaves the school - The school ends its contract with the vendor - A parent submits a deletion request

The answers should be specific. "We delete data upon request" is less reassuring than "We delete all student records within 30 days of contract termination and provide written confirmation."

IT teams also ask about backups. Does a backup of deleted records persist? For how long? Can it be purged on request?

6. Breach notification timeline

Post-breach notification requirements vary by jurisdiction, but IT departments have their own expectations on top of the legal minimum.

Most districts we have worked with want: - Notification within 24-72 hours of discovery - A named contact (not a generic support email) who will be the point of contact during an incident - A written incident response plan that they can review before approval

7. Pilot isolation

Many IT teams will approve a pilot for a limited group of students before district-wide rollout. They want to know whether the vendor supports a pilot mode that limits data collection to the pilot cohort and does not commingle pilot data with other clients' data.

This is also a good moment to discuss SSO. Districts that use Google Workspace for Education or Microsoft 365 Education will prefer (or require) that students authenticate via the district's identity provider rather than creating separate credentials.

Making the process faster

The vendors that move through IT review most quickly are the ones who arrive with documentation already prepared. If you are advocating internally for a new tool, the most useful thing you can do is ask the vendor for:

1. A completed data privacy agreement (or the willingness to sign the district's standard DPA)
2. A subprocessor list
3. An infrastructure overview with storage regions named
4. A contact name for the district's security team

With those four documents in hand, most review processes move from months to weeks.

A note on timing

District IT calendars are not arbitrary. Review timelines tend to compress before summer (because schools want tools ready for the fall semester) and expand during high-traffic periods like Q4 budget season.

If you want a new tool live by September, start the IT review by March. If you are in Canada and have Quebec schools in scope, start earlier - the Law 25 assessment adds meaningful time.

The teachers and department heads who get new tools approved are almost always the ones who started the conversation three months before they needed an answer.