Security Review Processes for Third-Party EdTech Integrations
Schools bear full liability for student data but lack legal power over vendors who hold it.
A school this size runs roughly 1,449 different EdTech tools, according to SecurePrivacy, and every single one is a door into student records. Most districts don't have a process for vetting who's walking through those doors. They have a purchase order and a prayer.
That's the actual state of security review in K-12 and higher ed right now. Not broken exactly, just missing. And the market keeps growing to fill the gap with more tools, not fewer: the global EdTech market hit $187.0 billion in 2025, with K-12 alone pulling 38.9% of that revenue, per Grand View Research. Vendors show up faster than anyone can vet them, data moves between LMS platforms and third-party apps and admin systems with no one tracking where it lands, and the legal structure underneath all of it is oddly lopsided.
Here's the part that should bother you more than it probably does: FERPA makes the school liable for what happens to student data, full stop, but gives the school almost no power over what a vendor actually does with that data once it's handed over. Third-party providers carry no direct statutory obligation under FERPA. There's no federal security baseline they have to meet. The school holds the bag; the vendor holds the data. A repeatable, documented review process is the only lever a school actually has to close that gap, and it's not paperwork for paperwork's sake. It's closer to a seatbelt: mostly invisible until the day it isn't.
What the breach record actually shows about how third-party tools become the attack vector
Between July 2023 and December 2024, 82% of K-12 schools experienced a cyber incident, according to the Center for Internet Security, adding up to more than 9,300 confirmed events in that window. That's not a rare bad month. That's Tuesday.
K12 SIX's research puts the vendor angle in sharp focus: at least 75% of data breaches hitting U.S. K-12 schools trace back to incidents involving a vendor or partner. Not the district's own firewall. Not a phishing email to a teacher. A third party, sitting in the supply chain, quietly becoming the weakest link.
Take PowerSchool, December 2024. One compromised credential, no multi-factor authentication on a customer support portal, and suddenly records tied to roughly 62 million people across about 18,000 North American schools were exposed. Names, birthdates, medical information, Social Security numbers, all of it. The company paid a ransom anyway, and the eventual class action settlement landed at $17.25 million. One overlooked login screen. That's the whole story. It's the security equivalent of leaving your house key under the mat and being shocked when someone finds the mat.
Canvas tells a different version of the same lesson. In the Instructure breach of April and May 2026, nobody stole a password; attackers exploited software vulnerabilities baked into the platform itself, hitting 8,809 institutions worldwide. ShinyHunters claimed 3.65 terabytes of data pulled from roughly 275 million users. Canvas runs at 41% of U.S. higher ed institutions, so a flaw in one platform became a flaw in nearly half the country's colleges simultaneously. A second vulnerability got exploited after the first one was already patched, and defacement hit Harvard, Penn, Duke, and Wisconsin on the way down. Instructure paid a ransom and got "shred logs" back as proof the stolen data was destroyed. Except there's no real way to verify that a deleted file is actually gone; you're taking someone's word for it, and that someone just got hacked.
Here's the layer that makes this worse than it looks: 96% of apps used or recommended in K-12 schools share student personal information with third parties, per Internet Safety Labs, and a significant portion of that sharing goes to advertisers or other profit-driven entities. So even tools that never get breached are quietly leaking data sideways as a matter of normal operation. The financial exposure reflects it. Education averages $4.45 million per breach, with ransom demands regularly clearing $450,000. That's not a rounding error in a district budget. That's the district budget.
The compliance landscape a security review must navigate before a tool is approved
FERPA is the anchor law here, governing who can access a student's educational record and for what purpose. But the enforcement gap is baked in: a vendor holding student data has no direct FERPA obligation, so liability sits entirely with the school even when the data never touches a school-owned server. There's no federal guidance spelling out what "direct control" over a vendor's data use is even supposed to mean in practice. It's a rule with a hole in the middle of it.
COPPA covers different ground, applying to tools touching kids under 13, which sounds like relief until you realize the school still has to verify compliance before rolling the tool out to a classroom. Parental consent is supposed to happen before data collection starts — a step that adds compliance burden to every classroom tool deployment.
States have started filling the federal gaps themselves, and fast. Roughly 150 new student privacy laws have passed across more than 40 states over the last decade, and CoSN's 2024 Education Cybersecurity Policy report clocks a 620% jump in new state cybersecurity and data privacy laws in 2023 compared to 2020. That legislative trend is accelerating across the country. Most states now expect districts to actually evaluate vendor security, not just get a signature on a form.
Put plainly, a review checklist has to sit on top of two layers at once: the federal floor and whatever the home state has bolted onto it. That combination decides which contract terms are actually mandatory. The Instructure lawsuit filed before the Canvas breach, back in March 2025, shows what happens when this gets ignored. The complaint pointed to 19 separate, scattered policy documents on Instructure's site as evidence of a privacy violation in itself. The fragmentation wasn't a footnote. It was the argument.
Step one — building a vendor assessment questionnaire that goes beyond the marketing sheet
A glossy sales deck tells you what a vendor wants you to know. A good questionnaire asks what they'd rather not say. Start with the basics: what data does the tool collect, store, and move, and in what format? Separate data the product needs to function from data getting siphoned off for analytics, advertising, or "product improvement." That second category is where the trouble lives. Vendors may not fully disclose how learner data gets collected and shared, which is exactly why the questionnaire needs to exist. It's not there to confirm what you already know. It's there to surface what nobody volunteered.
Ask for actual security certifications, not a logo on a webpage. SOC 2 Type II or ISO 27001, and request the real report, not a marketing summary of it. Ask about penetration testing too: how recent, who ran it, what got fixed afterward.
Access control deserves its own line of questions. Is MFA enforced everywhere, including the vendor's own support and admin portals? Remember, PowerSchool's breach started at a support portal with no MFA at all. Ask whether the tool follows least-privilege principles, meaning it only touches the data it genuinely needs and nothing more.
Then there's incident response. What's the vendor's contractual promise for notifying you after a breach, and how fast? What proof will they give you that stolen data actually got contained? Canvas's "shred logs" should be a case study in why a promise isn't evidence.
Last, ask for a full list of subprocessors and API partners. The pre-breach Canvas lawsuit specifically named the API layer as the channel through which outside developers reached student data, so a vendor's downstream partners matter as much as the vendor itself. None of this works as a checkbox exercise. Score every answer against a rubric, and treat anything that can't be backed up with documentation as a warning sign, not a passing grade.
Step two — mapping what data actually moves, to whom, and under what permissions
The questionnaire tells you what the vendor claims. Data mapping tells you what your school actually authorized, which is a different and more honest question. For every integration, trace three things: what data types are flowing out (directory info, grades, behavioral data, health records, device IDs), which direction it moves and whether the vendor keeps it after the contract ends, and who on the vendor's side can actually see it.
Sort everything by sensitivity before deciding how much scrutiny it needs. Directory-level information like a name or grade level sits at one end. Behavioral and engagement data sits in the middle. Health records, financial data, and disciplinary records sit at the top, and they deserve the tightest controls in the building; Social Security numbers and medical records were exactly what got exposed in the PowerSchool breach.
Every data share also needs a documented legal basis. That might be the FERPA "school official" exception, COPPA parental consent, or a state-specific authorization. Write it down. Undocumented flows are the ones that turn into exhibits in a lawsuit later.
With 1,449 tools floating around an average school, nobody's mapping this by hand across the board, and that's fine. But any tool above a minimal data threshold needs a documented record before it ever touches student PII. The output of all this becomes a living inventory, the school's own record of what's authorized, where it goes, and why.
Step three — the contractual terms that convert vendor promises into enforceable obligations
Nothing federal requires a written contract before a vendor gets student data. That means the school has to demand one, unilaterally, every time. No contract, no data. Simple as that.
For any tool touching student PII, a handful of terms are not optional. Purpose limitation locks the data to the contracted educational use, ruling out advertising or resale. Deletion terms need a hard timeline once the contract ends, with a confirmation step, not just a promise. Breach notification needs a specific window, often 72 hours under newer state laws, plus a clear list of who gets contacted and what the notice has to say. Subprocessor restrictions stop a vendor from quietly adding new downstream partners without written consent. And audit rights let the school actually ask for proof, SOC 2 reports, pen test results, current subprocessor lists, whenever it wants them.
MFA belongs in the contract itself, not left as an internal vendor policy nobody outside the company can see. If PowerSchool's support portal had been contractually required to run MFA, the district would've had recourse before the breach instead of a settlement check after it.
States with their own laws need their own addenda too; Many newer state laws are specific enough that a generic contract won't satisfy them. And for any tool touching sensitive data, legal counsel has to review the contract. IT and procurement can spot a red flag, but they can't judge what's actually enforceable in court.
Step four — a structured technical review before a tool goes live in the environment
Match the depth of the technical review to how much data the tool actually touches. A read-only tool working with anonymized usage stats doesn't need the same scrutiny as something running a live, bidirectional sync with student records. The sensitivity tiers from Step Two should drive this decision directly, not gut feeling.
Check authentication first. Confirm MFA is enforced at every access point, including the vendor's admin and support portals, not just the login screen students see. Verify single sign-on is wired correctly and doesn't spin up shadow accounts your identity system doesn't know about. Look closely at API token handling too. Canvas fell to platform-level bugs rather than stolen passwords, and access tokens remain a favorite target for groups like ShinyHunters.
Review how data moves across the network. Confirm encryption in transit meets current standards, and check where the data physically lives, since storage location can trigger cross-border transfer rules under state or international law.
Run a permission scoping test before full rollout. Put the tool in a sandbox and confirm it only asks for the data fields it declared upfront. If it wants more than its stated job requires, that's a flag, not a formality.
Finally, ask how fast the vendor patches known vulnerabilities. Canvas got hit through a second flaw discovered right after the first one was fixed, so patch speed isn't a technical footnote, it's a direct measure of how exposed you stay after go-live. Document every finding. That record becomes part of the approval file and the audit trail if anyone ever asks questions later.
Step five — an approval workflow that prevents tools from bypassing the process entirely
Most schools don't fail here because the checklist is bad. They fail because nobody owns the decision. IT, procurement, and curriculum staff often move in three separate lanes with no single person or office holding the final gate, which means a teacher can adopt a free app on a Tuesday afternoon and nobody finds out until it's already syncing gradebook data.
Fix that by tiering approval authority to match data sensitivity. Tools with no student PII get department-level sign-off from IT, quick and low-friction. Tools touching student PII need a full package: completed questionnaire, data map, and signed contract terms, reviewed by whoever holds privacy authority in the district. And tools reaching into the most sensitive tiers, health records, disciplinary files, financial data, need the highest bar of all: privacy officer review, legal counsel sign-off, and a technical review completed before a single student account gets provisioned.
The workflow only holds if there's no side door. Every purchase order, every free-tier signup, every "let's just try this app" moment from a teacher has to route through the same gate. Otherwise the review process becomes something schools have on paper and ignore in practice, which is exactly the ad-hoc mess this whole approach was built to replace.
