A Data Security Compliance Checklist for AI Tools in Schools

A secure AI tool for schools needs five technical safeguards regardless of which privacy law applies: encryption in transit and at rest, role-based access control with single sign-on, a documented incident response plan with a defined breach-notification timeline, a vetted vendor security posture (SOC 2 or equivalent), and a written data retention and deletion policy. These five hold up under FERPA, COPPA, GDPR, and general security best practice alike, because they describe how data is protected, not which law happens to apply.

Quick Answer: Before adopting an AI tool with student data, verify encryption (TLS 1.2+ in transit, AES-256 at rest), centrally managed access via SSO with role-based permissions, a written incident response plan with a specific breach-notification window, a current SOC 2 report or equivalent audit, and a documented, enforced retention and deletion schedule. Pass all five, and a vendor has cleared the technical baseline, separate from whatever legal contract a district still needs to sign.

Here's a distinction worth drawing before anything else: legal compliance and data security are related, but they are not the same checklist. A signed Data Processing Agreement tells you a vendor has agreed, on paper, to specific rules about how student data gets used. It says nothing about whether that vendor encrypts its database, revokes a departing employee's access promptly, or even knows when it's been breached.

This guide is the technical half. For the legal and contractual half, framework by framework, see EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026), How Schools Can Use AI Without Violating GDPR, and GDPR and AI in Education: A Guide for Administrators. Neither half substitutes for the other; a tool can pass every item below and still lack a signed contract, and vice versa.

Why a Security-First Checklist, Separate From the Legal One

A district can have every contract signed correctly and still get breached, because a DPA is a promise about intent, not a guarantee about implementation. Two real incidents from the past two years make the gap concrete.

In December 2024, PowerSchool, a widely used student information system, suffered a breach that TechCrunch traced to a single compromised support-portal credential, exposing the names, addresses, and in many cases Social Security numbers of more than 62 million students and 9.5 million teachers (TechCrunch, 2025). The company's contracts weren't the problem; a single unmonitored access point was.

Illuminate Education's breach ran even deeper into avoidable technical failure. Attackers used the still-active login credentials of a former employee to access unencrypted databases between late December 2021 and early January 2022, exposing the personal data of more than 10 million students across districts including New York City and Los Angeles Unified.

The Federal Trade Commission's December 2025 enforcement action found the company had failed to encrypt student data, failed to decommission inactive accounts, and failed to limit account permissions to what was actually necessary (FTC, 2025). That was serious enough that a multistate coalition led by New York's Attorney General separately secured a $5.1 million settlement in 2025.

Neither breach happened because a contract was missing. Both happened because a specific, checkable technical control wasn't in place. That's the case for treating security as its own checklist, run alongside, not instead of, the legal one.

The Five-Domain Security Checklist, at a Glance

Run every AI vendor through these five domains before student data touches the product, and document the answer for each one, not just a verbal assurance from a sales call.

Domain 1: Encryption, in Transit and at Rest

Encryption protects data two different ways depending on where it sits, and a vendor needs to answer for both, not just one. "We use encryption" is not a complete answer until you know which kind, and where.

• In transit, data moving between a teacher's browser and the vendor's servers should use TLS 1.2 or higher, the standard that prevents interception on an open network, like a school's guest Wi-Fi.
• At rest, data sitting in a database should be encrypted using a strong standard such as AES-256, so a stolen database file or backup isn't readable without the encryption key.

Illuminate Education's 2022 breach is the clearest cautionary example here: the FTC's finding specifically cited unencrypted data at rest as a root cause, meaning the stolen files were immediately usable the moment an attacker got in, with no additional barrier to clear (FTC, 2025).

Questions to ask the vendor directly

1. Is student data encrypted at rest, and with what standard?
2. Is all data in transit encrypted, including internal traffic between the vendor's own services, not just the customer-facing connection?
3. Who holds the encryption keys, the vendor or a separate key-management service?
4. Are backups encrypted to the same standard as the live database?

Domain 2: Access Control and Identity Management

A district that can't answer "who currently has access to our data" has an access-control gap, regardless of what the vendor's marketing page claims about security. This is the domain FERPA's "direct control" requirement and GDPR's Article 32 both point toward, even though they're different laws.

Look for these three components, together, not individually:

• Single sign-on (SSO) tied to the district's own identity system, so account creation and removal happen centrally, not one teacher email signup at a time.
• Role-based access control, meaning a teacher's account can't see district-wide administrative settings, and a substitute's temporary account doesn't retain access after the assignment ends.
• Multi-factor authentication (MFA), at minimum for any administrative or district-level account, since a single compromised password is exactly how the PowerSchool breach began (TechCrunch, 2025).

A tool where every teacher signs up individually with a personal email, no domain verification, no central roster, makes it functionally impossible for IT to prove who has access if ever asked, which is precisely the gap that undermines a district's legal position under FERPA's school-official exception too.

Domain 3: Incident Response and Breach Notification

A vendor without a written incident response plan is a vendor that improvises during the exact moment speed matters most, and different laws set different clocks running the moment a breach is discovered.

The notification timelines aren't identical across frameworks, which is exactly why a district needs to know which ones apply:

• GDPR's Article 33 requires notifying the relevant supervisory authority within 72 hours of becoming aware of a breach, where feasible, with reasons required for any delay.
• US state breach-notification laws vary by state, commonly requiring notification "without unreasonable delay," with some states specifying an exact number of days.
• COPPA's 2025 amendments tightened requirements around documenting and communicating data practices, including third-party disclosures, though COPPA itself doesn't set a single fixed breach-notification clock the way GDPR does.

A written incident response plan should name a specific responsible contact, describe how affected districts get notified and on what timeline, and specify what happens to compromised data. Ask for this document before signing, not after an incident forces the question.

Domain 4: Vendor Security Posture and Third-Party Audits

A SOC 2 report is the single most useful piece of paper a vendor can hand a district, because it means an independent auditor, not the vendor itself, checked the vendor's actual controls. It's not a legal certification, and it doesn't cover data-training or retention practices by itself, but it's real, verifiable evidence a technical review happened.

SOC 2 is built around the AICPA's Trust Services Criteria, five categories a vendor can be audited against:

1. Security (mandatory for every SOC 2 report; covers access controls, risk management, and incident response basics)
2. Availability (uptime, backups, disaster recovery)
3. Confidentiality (protecting non-public information from unauthorized exposure)
4. Processing integrity (whether the system works correctly and completely)
5. Privacy (whether personal data is handled per stated policy)

A Type II report is stronger evidence than a Type I. Type I confirms controls existed on a single date; Type II confirms they operated effectively over a period, typically six to twelve months, which is a meaningfully higher bar.

Beyond the audit itself, ask the vendor to name its subprocessors, the other companies (including the underlying AI model provider) that touch the data downstream. A vendor that won't name them can't have those protections independently verified, no matter how strong its own SOC 2 report looks.

Domain 5: Data Retention and Deletion

"We keep data as long as necessary" is not a retention policy; it's the absence of one, and every framework this checklist spans has moved toward requiring something more specific. The FTC's 2025 COPPA amendments now require a written, published retention timeline rather than an open-ended promise, and GDPR's Article 5(1)(e) requires data to be kept "no longer than is necessary" for its stated purpose, which regulators interpret as requiring an actual defined window, not just good intentions.

A complete retention answer specifies three things:

• A defined retention window (30 days, 12 months, until contract termination), stated in writing.
• What happens automatically when a student leaves the district or a contract ends, deletion by default, or does the district have to request it.
• Whether deletion is verifiable, meaning the vendor can confirm, on request, that specific data has actually been removed, not just marked inactive.

Shadow AI: The Security Risk No Checklist Catches Once It's Already Happening

A checklist only works on tools a district knows about, and right now, most AI use in classrooms happens before anyone runs a checklist at all. According to CoSN's May 2025 State of EdTech District Leadership report, 80% of districts have generative AI initiatives already underway, while 43% still lack formal policies or guidance governing that use (CoSN, 2025). That gap is where unreviewed, unencrypted, unvetted tools quietly accumulate student data.

"Shadow AI" describes exactly that pattern: a teacher finds a free tool, tries it with a class, likes the results, and keeps using it, all without IT or a privacy officer ever running the five-domain checklist above. None of this is usually malicious. It's what happens when a genuinely useful tool moves faster than a district's review process.

Two structural fixes close most of this gap:

• A named, pre-approved tier of sanctioned tools, so a teacher who wants to try something new has a fast, real path to get it reviewed, rather than a blanket ban that just pushes the behavior underground.
• A lightweight self-service version of the checklist teachers can run themselves for a low-stakes pilot, non-identifiable content only, before escalating to IT for a full review once a tool proves useful enough to matter.

Building the Checklist Into Procurement, Not Just Onboarding

The checklist works best when it's a gate a tool has to clear before a contract is signed, not a review that happens after a pilot has already become permanent. Retrofitting security review onto a tool teachers already depend on is a much harder conversation than running it up front.

A workable procurement sequence looks like this:

1. Send the five-domain checklist to the vendor in writing as part of the RFP or trial request, before any student data touches the product.
2. Require a current SOC 2 report, or equivalent independent audit, as a condition of moving past a free trial into a paid or district-wide agreement. Some vendors instead hold an ISO 27001 certification, an international information-security management standard; either is meaningfully stronger evidence than a vendor's own self-description.
3. Ask whether the vendor has had a third-party penetration test within the last 12 months, and whether the findings, or at least a remediation summary, are available for review.
4. Document the answers to all five domains in one shared record, so the next department evaluating the same vendor doesn't start from zero.
5. Set a recurring review date, not a one-time approval, since vendor security postures, subprocessors, and retention defaults all shift over time.

A Classroom-Level Illustration: Why This Isn't Just an IT Problem

Say you're a Grade 6 humanities teacher piloting a new AI writing-feedback tool for a unit on persuasive essays. The pilot looks great in the classroom, faster feedback turnaround, more consistent rubric application, but none of that tells you whether the vendor encrypts the essays your students submit, or how long those essays sit in the vendor's database after the unit ends.

A tool like EduGenius, which keeps personally identifiable student information in server-side data structures rather than exposing it to the client and defaults new content to private sharing, illustrates the kind of architectural choice this checklist is designed to surface. The security posture sits underneath the classroom-facing features, not inside them, which is exactly why a pilot's visible results can't answer for it.

Related Reading

• AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
• Diffit and Student Data Privacy: What Teachers Should Know
• How Schools Can Use AI Without Violating GDPR
• GDPR and AI in Education: A Guide for Administrators
• SchoolAI and Student Data Privacy: What Teachers Should Know
• SchoolAI vs Khanmigo: Which Is Better for Teachers?