The EdTech Vendor Vetting Checklist: FERPA & SOPPA Questions to Ask Before You Sign
An EdTech vendor vetting checklist for an Illinois school really answers one question, twice. Does this vendor meet SOPPA’s operator duties? And does the data-sharing arrangement fit FERPA’s school-official exception? Every question below traces back to one of those two answers.
SOPPA is Illinois’s state-level student data privacy law. It sits on top of FERPA, the federal law schools already follow. Neither one replaces the other. A vendor can clear one test and still fail the second, so this checklist works through both, in the order you’d actually ask them on a vendor call.
Step 1: Is This Vendor Actually an “Operator” Under SOPPA?
Not every app a teacher uses falls under SOPPA. The law only regulates vendors that meet its operator definition (105 ILCS 85/5). That’s a two-part test. A vendor has to clear both halves, not just one.
- Actual knowledge. The vendor knows its product is used primarily for K-12 school purposes.
- Design and marketing. The product was built and marketed for K-12 schools, not adapted from a general-audience tool.
This is why a mainstream video-conferencing or file-storage product, one your district also uses for staff meetings and budget spreadsheets, can sit outside SOPPA’s operator definition even though a classroom uses it too. It wasn’t designed or marketed for K-12 school purposes. A purpose-built gradebook, assessment platform, or classroom app doesn’t get that same out. It was built for schools. That puts it in scope by design, and “we also have some non-school users” doesn’t change that.
One more scope note worth checking early: SOPPA’s operator duties only reach K-12 school purposes. A vendor whose product is used solely by a college or university isn’t an operator under SOPPA’s definition, even though FERPA still covers that institution separately. If you’re vetting a tool that spans a K-12 district and a community college partnership, the SOPPA analysis applies only to the K-12 side.
Ask the vendor directly which bucket they think they’re in, and why. If they can’t answer clearly, or they’ve never heard the term “operator” in this context, treat that as a yellow flag rather than a pass. For the law’s full background, see our Illinois SOPPA compliance guide.
Step 2: Before Any Data Moves, Confirm the Data Privacy Agreement
If the vendor is an operator, no covered information should move until a written data privacy agreement is signed (105 ILCS 85/15). The DPA can be electronic or click-wrap. It still has to be a real, specific document, not a generic terms-of-service page the vendor points you to.
A compliant DPA has to include, at minimum:
- The categories of covered information being shared
- A description of the product or service itself
- A FERPA school-official statement confirming the operator performs an institutional service under the school’s direct control, and won’t re-disclose data without permission
- An allocation of responsibility for costs if a breach happens
- A named time period for deleting or transferring the data back
Ask to see the actual document, not a summary in a sales deck. Districts are also required to make their signed DPAs available so parents can review them. If a vendor can’t produce a DPA, or tries to substitute a standard privacy policy, that’s not the same thing, and it’s not compliant. Our FERPA IT compliance checklist for Illinois schools walks through the FERPA access-control side of this same question in more depth.
One more practical step: check whether your district’s agreement is already on file. The Illinois State Board of Education keeps a running list of vendor data privacy agreements districts have submitted. If a vendor claims to already have a signed DPA with other Illinois districts, that’s worth a quick cross-check before you take their word for it.
Step 3: Ask What Happens to Our Data When the Contract Ends
This is the question sales calls tend to answer vaguely. Get it in writing instead.
Under SOPPA, an operator has to delete or transfer covered information back to the school once it’s no longer needed for the purpose it was collected for, unless a parent or eligible student consents to the operator keeping it. The DPA itself has to name the actual time period this happens in, not just describe the intent.
“We’ll delete it eventually” is not a DPA clause. A specific number of days is. If the contract in front of you is silent on the deletion or transfer window, that’s a gap to close before signing, not something to chase down after the fact. Push for the actual number, in writing, and hold the vendor to it.
Step 4: Get the Breach-Notification Clock in Writing
Ask the vendor one direct question: how fast will you tell us if our students’ data is breached?
SOPPA answers this with a hard deadline, not a vague promise. An operator must notify the school of a breach in the most expedient time possible, and no later than 30 calendar days after determining a breach occurred (105 ILCS 85/15). That deadline matters because it starts a second clock. Once the school knows, the district has its own 30-day window to notify affected parents (105 ILCS 85/27).
| Who notifies | Notifies whom | Deadline |
|---|---|---|
| Operator (vendor) | The school or district | 30 calendar days after determining a breach occurred |
| School or district | Affected parents | 30 calendar days after learning of the breach |
A vendor contract that’s silent on this timeline is a real red flag. Without it, the school has no enforceable deadline to point to if something goes wrong, and no reliable way to hit its own 30-day parent-notification window on time. For a look at what vendor-side exposure actually looks like when this goes badly, our FERPA violation examples for schools roundup covers the vendor-exposure pattern directly.
Step 5: Check What the Vendor Is Never Allowed to Do
Some restrictions apply no matter what the contract says. SOPPA prohibits an operator from three things outright, regardless of what any DPA authorizes (105 ILCS 85/10):
- Targeted advertising to students, based on data collected through the service
- Building a profile of a student for any purpose other than the K-12 school purpose the data was collected for
- Selling or renting a student’s covered information
Ask the vendor directly whether their business model touches any of these. This matters most with free or freemium products. An ad-supported free tier is the most common place this rule gets broken, since the business model itself can depend on the kind of profiling SOPPA prohibits. A vendor that hesitates on this question, or answers with “we don’t sell data, we just share it with partners,” hasn’t actually answered it. Push for a plain yes or no on each of the three items above, and get the answer in writing if the product is free or ad-supported.
Step 6: What’s Allowed Even Under a Compliant DPA
Not every data use is a violation. Some analytics work is fine, even under SOPPA’s tight rules.
The Section 25 exception lets an operator use de-identified covered information for real product work (105 ILCS 85/25). None of these uses require extra permission, as long as the data isn’t tied back to an identified student:
- Improving the educational effectiveness of the product
- Demonstrating the product’s effectiveness, including in marketing materials
- Sharing de-identified data to help develop other educational sites, services, or apps
- Powering a recommendation engine, as long as it isn’t paid for by a third party
So a vendor saying “we run analytics on de-identified data” isn’t automatically a red flag. The checklist item is verifying the de-identification is real, not just a label on a privacy page.
Ask specifically what fields get stripped before analysis. Ask whether the data is aggregated across enough students that no individual is identifiable. A vague “we anonymize it” answer deserves a follow-up question, not a pass.
Step 7: Confirm FERPA’s Access Scoping on the Technical Side
The school-official exception is what lets a vendor touch student data at all under FERPA (34 CFR 99.31(a)(1)). That same rule limits the vendor to only what it needs.
Ask whether the platform can be configured so a teacher, staff account, or vendor login reaches only the records the tool’s function actually requires. Access scoped by school, grade, or class roster fits “legitimate educational interest.” Access that’s all-or-nothing, where every login sees every student in the district, doesn’t.
Push the vendor on this directly. Can permissions be scoped that narrowly, or is broad access just how the platform is built?
Step 8: Security Baseline Questions to Ask
FERPA doesn’t hand schools a specific technical checklist. It requires “reasonable methods” to keep access limited to legitimate educational interest (34 CFR 99.31(c)). In practice, that means asking the vendor a short set of concrete questions.
- Does every account with access to covered information require multifactor authentication?
- Is data encrypted both at rest and in transit?
- Can the vendor produce evidence of its own security practices on request?
The MFA question isn’t hypothetical. The cause traced back to one compromised support-portal credential, with no multifactor authentication in place to stop it from reaching the underlying system.
That’s the failure mode this question is built to catch. A vendor that hesitates on MFA, or treats it as optional, is telling you something.
Step 9: Check the Exemption List Before You Assume SOPPA Applies
Not every tool a school uses is in scope. SOPPA’s Section 30 exempts several categories from its operator-facing requirements (105 ILCS 85/30), including:
- General audience websites or online services, even when accessed through a school-issued login
- Tools used only for adaptive or customized learning purposes
- App-store or digital-marketplace providers that merely distribute an app
- School yearbook or class-photo vendors operating under a written agreement
If a vendor’s product falls into one of these categories, the DPA requirement in Step 2 may not apply the same way. That changes what you ask for. Confirm which exemption the vendor is claiming, and why, rather than taking “we’re exempt” at face value.
Section 30 also confirms SOPPA doesn’t reduce whatever protections FERPA and the Illinois School Student Records Act already provide. The laws stack. An exemption from SOPPA’s operator duties doesn’t exempt a vendor from FERPA.
The Vetting Checklist, All in One Table
Use this as the working document on the actual vendor call.
| Question to Ask the Vendor | Citation | What a Passing Answer Looks Like |
|---|---|---|
| Are you designed and marketed for K-12 use, with actual knowledge we use you that way? | 105 ILCS 85/5 | A clear yes or no, with reasoning, not a shrug |
| Do you have a signed data privacy agreement covering our categories of data? | 105 ILCS 85/15 | An actual DPA document, not a general privacy policy |
| What happens to our data when the contract ends? | 105 ILCS 85/15 | A specific deletion or transfer window, named in writing |
| How fast will you notify us of a breach? | 105 ILCS 85/15 | 30 calendar days or faster, stated in the contract |
| Do you use student data for advertising, profiling, or sale? | 105 ILCS 85/10 | A direct no, in writing |
| Is your de-identified data use actually de-identified? | 105 ILCS 85/25 | The vendor can explain the method, not just assert it |
| Can access be scoped to only what a role needs? | 34 CFR 99.31(a)(1) | Granular, role-based access controls, not all-or-nothing |
| Do you require MFA and encryption on data with covered information? | 34 CFR 99.31(c) | Yes to both, and the vendor can show it |
| Are you claiming a Section 30 exemption? If so, which one? | 105 ILCS 85/30 | The vendor names the specific exemption, not a blanket claim |
See Where You Stand
Not sure your existing vendor contracts would actually pass this checklist. Our free 2-minute FERPA & SOPPA Risk-Check walks through the same access-control, vendor-agreement, and breach-notification questions above, and gives you a gap list at the end. No sign-up required to see your result.
Take the free 2-minute FERPA & SOPPA risk assessment
Related Guides
- Illinois SOPPA Compliance: The Plain-English Guide
- The FERPA IT Compliance Checklist for Illinois Schools
- FERPA Violation Examples: What They Look Like and How Schools Prevent Them
Frequently Asked Questions
Only if the vendor qualifies as an operator under SOPPA’s two-part test: actual knowledge the product is used primarily for K-12 school purposes, plus design and marketing built for K-12 schools. A general-purpose tool your school also happens to use may fall outside that definition. Confirm operator status first, then require the DPA only if it applies.
If a vendor qualifies as an operator under SOPPA, no covered information may transfer to them without a signed DPA in place first. A vendor that refuses to sign one can’t lawfully receive student data from an Illinois school. At that point the choice is to find another vendor, or use the product only in ways that never involve covered information.
Not automatically. Free doesn’t equal exempt. What matters is whether the app meets SOPPA’s operator definition, not its price. Some free, general-audience tools do fall under Section 30’s exemptions, but a purpose-built classroom app given away for free can still be an operator, and ad-supported free tiers deserve extra scrutiny under the ban on targeted advertising to students.
Both sides carry a deadline. The operator must notify the school within 30 calendar days of determining a breach occurred. That starts the school’s own clock: the district must then notify affected parents within 30 calendar days of learning about it. A contract silent on the vendor’s notification timeline leaves the school without an enforceable deadline to point to.
It’s the provision that lets a school share education records without consent with a school official, which can include a contracted vendor, who has a legitimate educational interest in the record. That interest means the vendor needs the data to fulfill a specific, defined responsibility, not broad access for convenience. It’s the legal basis that lets any EdTech vendor touch student data at all.
Ready to Get This Off Your Plate
Working through this checklist for one vendor is manageable. Doing it for every EdTech tool your district uses, and keeping DPAs current, access scoped, and MFA enforced across dozens of vendor logins, is a bigger job than most school IT teams have time for.
LeadingIT’s school IT compliance services handle the vendor review and the technical side of FERPA and SOPPA together, so this checklist doesn’t sit on one person’s desk.
Want our cybersecurity insights first? Add LeadingIT as a preferred source on Google and see more of our guidance in your results.
