Security Review Processes for Third-Party EdTech Integrations

The average school 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 no formal review system.

That's the actual state of security review in K-12 and higher ed right now: not broken exactly, just missing. 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.

FERPA makes the school liable for what happens to student data, 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. A repeatable, documented review process is the only lever a school actually has to close that gap.

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.

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 or a phishing email to a teacher.

In December 2024, one compromised credential and no multi-factor authentication on a PowerSchool customer support portal exposed records tied to roughly 62 million people across about 18,000 North American schools. Names, birthdates, medical information, and Social Security numbers were all included. The company paid a ransom, and the eventual class action settlement landed at $17.25 million.

The Instructure breach of April and May 2026 followed a different pattern. Attackers exploited software vulnerabilities baked into the Canvas 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 was exploited after the first one was already patched, and defacement hit Harvard, Penn, Duke, and Wisconsin. Instructure paid a ransom and received "shred logs" as proof the stolen data was destroyed, but there is no reliable way to verify that deleted files are actually gone.

Beyond breaches, 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. Tools that never get breached are still quietly transferring data 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.

Compliance Laws a Security Review Must Navigate

FERPA is the anchor law here, governing who can access a student's educational record and for what purpose. 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 supposed to mean in practice.

COPPA covers tools touching kids under 13, and the school still has to verify compliance before rolling a tool out to a classroom. Parental consent is required before data collection starts, which adds compliance burden to every classroom tool deployment.

States have started filling the federal gaps themselves. 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. Most states now expect districts to actually evaluate vendor security, not just collect a signed form.

A review checklist has to sit on top of two layers at once: the federal floor and whatever the home state has added to it. That combination decides which contract terms are actually mandatory. The Instructure lawsuit filed before the Canvas breach, 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.

Build a Vendor Questionnaire Beyond the Marketing Sheet

A good questionnaire asks what vendors would rather not volunteer. 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 used for analytics, advertising, or product improvement. Vendors may not fully disclose how learner data gets collected and shared, which is exactly why the questionnaire needs to exist.

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. Ask about penetration testing: how recent, who ran it, and 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? 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.

Then there's incident response. What's the vendor's contractual commitment for notifying you after a breach, and how fast? What proof will they provide that stolen data was actually contained? The Canvas "shred logs" illustrate why a promise is not the same as evidence.

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. Score every answer against a rubric, and treat anything that can't be backed up with documentation as a warning sign.

Map Where Student Data Actually Goes

The questionnaire tells you what the vendor claims. Data mapping tells you what your school actually authorized. 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 retains 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 sits at one end. Behavioral and engagement data sits in the middle. Health records, financial data, and disciplinary records sit at the top and require the tightest controls. Social Security numbers and medical records were exactly what got exposed in the PowerSchool breach.

Every data share also needs a documented legal basis: the FERPA "school official" exception, COPPA parental consent, or a state-specific authorization. Undocumented flows are the ones that become exhibits in litigation later.

With 1,449 tools floating around an average school, nobody maps every one by hand, and that's acceptable. But any tool above a minimal data threshold needs a documented record before it ever touches student PII. The output of this step becomes a living inventory of what's authorized, where it goes, and why.

Contracts That Make Vendor Promises Enforceable

Nothing federal requires a written contract before a vendor gets student data. The school has to demand one unilaterally, every time.

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. 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 must include. Subprocessor restrictions prevent a vendor from quietly adding new downstream partners without written consent. Audit rights let the school request proof, including SOC 2 reports, penetration test results, and current subprocessor lists.

MFA should appear in the contract itself, not left as an internal vendor policy. If PowerSchool's support portal had been contractually required to run MFA, the district would have had recourse before the breach rather than a settlement afterward.

States with their own laws need their own addenda. Many newer state laws are specific enough that a generic contract won't satisfy them. For any tool touching sensitive data, legal counsel has to review the contract before it's signed.

Run a Technical Review Before Tools Go Live

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 the data mapping step should drive this decision.

Check authentication first. Confirm MFA is enforced at every access point, including the vendor's admin and support portals. Verify single sign-on is configured correctly and doesn't create shadow accounts your identity system doesn't track. Review API token handling closely. Canvas fell to platform-level vulnerabilities rather than stolen passwords, and access tokens remain a common target.

Review how data moves across the network. Confirm encryption in transit meets current standards, and check where the data physically resides, 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 requests the data fields it declared upfront. If it requests more than its stated function requires, that's a substantive concern.

Ask how fast the vendor patches known vulnerabilities. Canvas was hit through a second flaw discovered right after the first one was fixed, so patch speed is a direct measure of ongoing exposure after go-live. Document every finding as part of the approval file and the audit trail.

Build an Approval Workflow With No Side Doors

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 separate lanes with no single person or office holding the final gate, which means a teacher can adopt a free app 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. 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. Tools reaching into the most sensitive tiers, including health records, disciplinary files, and financial data, require privacy officer review, legal counsel sign-off, and a completed technical review before any student account is provisioned.

The workflow only holds if there is no side door. Every purchase order, every free-tier signup, and every informal tool adoption from a teacher has to route through the same gate. Otherwise the review process exists on paper but fails in practice, which is the ad-hoc situation this approach was built to replace.