Penetration Testing Scope and Cadence for EdTech SaaS Vendors

In December 2024, a cloud-based student records provider serving tens of thousands of schools and tens of millions of students across North America got breached: tens of millions of student records gone, millions of teacher records with them, in what's now considered the largest breach of children's data in U.S. history. That's PowerSchool. And it's an example of why EdTech SaaS vendors occupy an unusual structural position, holding student records, attendance data, and increasingly biometric information on behalf of institutions that cannot protect themselves, making vendor-layer security failures a systemic risk to millions of minors.

The structural problem is this. EdTech vendors hold student records, attendance logs, and biometric data on behalf of schools that mostly don't have the staff or budget to secure any of it themselves. CISA's K-12 Cybersecurity Initiative has a blunt way of putting it: educational organizations are "target rich, cyber poor." The school is the door attackers walk through. The vendor is where everything valuable actually sits.

The scale of the targeting backs this up. Comparitech's Education Ransomware Roundup counted 251 confirmed ransomware attacks against education institutions worldwide in 2025, with 130 of those hitting the United States alone, and the breached-record counts from those attacks ran into the millions. This is a sector getting hit on a predictable schedule, not by random bad luck.

And regulators have started treating pen testing failures as the smoking gun. Illuminate Education is the case to know here. A 2022 breach exposed personal records belonging to millions of students, and by late 2025 the company had agreed to a multi-million-dollar settlement with the Attorneys General of New York, California, and Connecticut. The investigation behind that settlement found something specific and damning: a cybersecurity vendor had flagged "high risk" server vulnerabilities as far back as 2020, and Illuminate never fully fixed them. As part of the settlement, Illuminate is now legally required to run third-party penetration tests and independent security audits for years to come. What used to be a voluntary best practice has become a court-ordered obligation, and that's the direction the entire industry is heading.

What EdTech Compliance Demands from Testing

EdTech vendors answer to a compliance stack that includes FERPA, COPPA, a patchwork of state laws, and SOC 2. None of these actually spell out which security tests to run or how often. Regulators and buyers decide whether a vendor did enough, usually after a breach.

FERPA is the oldest and vaguest of the bunch. Once a school signs a contract with a SaaS vendor, that vendor becomes a "school official" under FERPA, on the hook to protect student records with the same care the school itself owes. But FERPA never names a control set and never mandates a testing type. The standard of care remains undefined until a breach forces someone to define it in hindsight.

COPPA just got a lot less vague. The FTC finalized major amendments to the COPPA Rule in January 2025, published them in the Federal Register that April, with compliance required by April 22, 2026. The headline change: "personal information" now explicitly includes biometric identifiers, fingerprints, voiceprints, and facial templates. There are also new requirements for written data retention policies and expanded notice rules. For any EdTech platform using facial recognition to mark attendance or voice recognition to grade a spoken assessment, that data now falls under a newly regulated category that must appear by name in a pen test's scope document.

SOC 2 is where all this gets operationalized. By 2026, schools and districts are screening vendors out at the procurement stage if they can't show security maturity, and a SOC 2 audit has become the standard way to prove it. SOC 2+ allows an EdTech vendor to use one report as the core assurance artifact while extending scope through structured mapping to COPPA or FERPA requirements, with the "plus" component selected based on contractual commitments and procurement requirements. Pen testing here functions as a deal-closing requirement: without it, a vendor often never reaches the security questionnaire stage.

What Pen Test Scope Must Cover

Start with the failure that actually exposes student records most often. It's rarely a dramatic perimeter breach. It's a cross-tenant authorization flaw, where tenant A quietly reads tenant B's data. Catching that requires testing at least two tenant accounts simultaneously, and most standard providers running single-session OWASP checks don't do that. In EdTech specifically, "tenant" doesn't just mean district. It often means individual schools within a district, each with different access rights to the same underlying system. A scope document built on a flat two-tenant assumption misses that hierarchy entirely.

The API layer deserves its own line item. Broken object-level authorization (BOLA) appears repeatedly as one of the most common findings across API-driven applications in the OWASP API Security Top 10, and Indusface's State of Application Security report for the first half of 2025 found API attacks surging year over year. EdTech platforms expose APIs constantly, to LMS integrations, rostering services, and parent portals, and each one is its own authorization boundary that needs to be named in scope.

Role logic matters just as much. Blaze InfoSec's 2025 penetration tests across Tech, Software, and SaaS clients found vulnerabilities clustering around access control, sensitive data exposure, and business logic, not at the network perimeter. A scope document that doesn't list every role, including student, teacher, administrator, district admin, parent, and API integration, will miss the authorization gaps between them.

Then there's the supply chain. Third parties were involved in nearly a third of breaches tracked in the 2025 Verizon DBIR. EdTech platforms typically connect to Student Information Systems, LTI tool providers, and SSO providers, and each of those connections creates an authentication delegation path that can sit outside a narrowly written scope. PowerSchool illustrates what happens when vendor-layer exposure cascades through an entire ecosystem. Because COPPA's 2025 amendments made biometric data a newly regulated category, any feature touching facial recognition, voiceprint, or fingerprint data must be named explicitly in scope.

A scope document for an EdTech platform should list by name: the student data API, the full district-and-school tenant hierarchy, every third-party integration with data access, every user role and its permissions, any biometric collection or processing pipeline, and the CI/CD paths that touch student data stores. If one of those is omitted, it is effectively untested.

Why Annual Testing Fails EdTech Vendors

Annual testing was designed for environments where the attack surface changes slowly. EdTech vendors ship new API endpoints, new integrations, and new features on a rolling basis. Security gets checked once while risk gets introduced continuously, and those two clocks don't run at the same speed.

Illuminate Education shows how that gap compounds over time. Vulnerabilities were flagged as "high risk" in 2020 and again in 2021. They remained unfixed by the time the 2022 breach occurred. That's a multi-year gap between identifying a problem and closing it, and an annual-or-slower testing cycle makes that gap structurally easy to miss.

There's a timing problem specific to EdTech's buying pattern as well. School procurement cycles don't run on a predictable calendar, so security questionnaires can arrive at any point in the year. A vendor whose last pen test happened 11 months ago is answering those questionnaires with evidence that's already going stale, and buyers' own security teams are increasingly catching that during due diligence.

The obvious pushback is that a SOC 2 auditor only requires annual testing. But that misreads what SOC 2 actually asks for. The Trust Services Criteria set a floor, not a ceiling, and the framework is principle-based, meaning auditors expect testing frequency to scale with risk. A fast-shipping EdTech platform with student data in scope is expected to clear a higher bar than a static internal tool.

The Right Cadence Model for EdTech

Neither extreme works on its own. Testing constantly with no deep manual review produces shallow findings; testing once a year produces stale ones. The model that fits EdTech is a hybrid: continuous or quarterly automated testing to close the deployment velocity gap, paired with an annual manual deep-dive that performs exploit-chain discovery and produces the auditor-ready evidence automated tools can't generate on their own.

Continuous testing means API authorization boundaries and tenant isolation get validated whenever a significant change touches those surfaces, usually through PTaaS platforms or autonomous AI testing tools running between manual engagement windows.

Specific events should trigger a test outside the normal annual cycle, and these are concrete enough to write into a policy document. Any new third-party integration that touches student data, including a new SIS connector, LTI tool, or SSO provider, should trigger one. Any new data type that falls under COPPA or a state law, especially biometric features now explicitly covered by COPPA's 2025 amendments, should trigger one. A meaningful change to the tenant hierarchy or role model belongs on that list too. So does a major release touching authentication, authorization, or data export pipelines, as well as the run-up to a SOC 2 Type II audit window or a district security questionnaire asking for recent evidence.

SOC 2 audits typically require annual penetration testing as a minimum but expect frequency to match risk. Documenting that trigger-based testing occurred in response to specific changes is evidence of a mature, risk-aligned program rather than a compliance checkbox.

PTaaS subscriptions that operationalize this kind of cadence cost more than a single annual engagement. Weighed against the cost of a breach or a procurement deal that dies in due diligence, the economics are straightforward. Illuminate's settlement is the regulatory floor this is all heading toward: the company is now legally bound to run third-party pen tests and independent audits for years, with outside accountability baked directly into the obligation.

How to Evaluate Pen Test Vendors

There's no single correct vendor for every EdTech company. The right choice depends on what's actually needed: auditor-ready compliance documentation, continuous coverage across a fast-moving API surface, or deep manual analysis of multi-tenant authorization logic that automated scanners can't reason through. Most mature security programs layer more than one vendor type rather than picking a single winner.

Before scoping any engagement, a handful of questions separate vendors who understand EdTech from those running the same checklist they'd run on any other application. Can they test two tenant accounts simultaneously to surface cross-tenant flaws? Does their API methodology cover BOLA and broken function-level authorization, or does it stop at generic OWASP Top 10 web checks? Will the final report map findings to SOC 2 Trust Services Criteria and tie back to COPPA and FERPA obligations by name? A vendor who can't answer these clearly is going to leave gaps exactly where EdTech platforms are most exposed.

On the hacker-led manual side, AppSecure Security is a useful example of what this looks like in practice. Its assessments are run by researchers with active bug bounty and CVE discovery backgrounds, covering multi-tenant authorization, API security, and business-logic abuse, with reports written to map directly onto SOC 2 Trust Services Criteria language. The firm positions itself as an "Agentic Penetration Testing Company," pairing manual testers with automation rather than treating them as alternatives. That combination, human judgment for deep manual work plus automated coverage between engagements, is the shape the hybrid cadence model calls for: continuous coverage of the fast-moving attack surface, plus the deep manual analysis that determines a breach's outcome. According to softwaresecured.com's ranked list, Software Secured is included among the evaluated penetration testing vendors.