Schools adopt a lot of software, and student data privacy is, understandably, one of the first things that gets asked about — and one of the easiest things for a vendor to answer vaguely. "We take privacy seriously" is not an answer. It's a sentence designed to sound like one. Before adopting any new tool that touches student information, it's worth having a specific checklist rather than accepting a general reassurance.
Start with what data is actually collected
The first, most basic question: what data does this tool actually touch, and why does it need each piece? A tool that needs student names and course rosters to function is different from a tool that also wants access to a student's entire Drive, or location data, or anything unrelated to what it's actually supposed to do. If a vendor can't clearly explain why they need a specific piece of data, that's worth pausing on.
The checklist
A few concrete questions worth asking any EdTech vendor, before signing anything:
- What specific data is collected, and what is each piece used for?
- Is student data ever used to train general AI models, or only to serve the immediate feature it's collected for?
- Is data sold, shared, or transferred to third parties for advertising or any purpose beyond the service itself?
- How is data secured — encrypted in transit, encrypted at rest, who has access internally?
- What happens to data when a school stops using the product? Is deletion guaranteed, and within what timeframe?
- Is access properly scoped, so a school administrator can only see data from their own school, not other schools using the same platform?
- Does the tool comply with relevant frameworks? For U.S. schools, that typically means FERPA and, for younger students, COPPA; for tools using Google Workspace data, Google's own API Services User Data Policy.
Reading a privacy policy like it matters
Most privacy policies are long, and it's tempting to skim for the headline and move on. It's worth reading, specifically, the sections on data sharing and data retention — those are the two places vague language does the most damage. "We may share data with trusted partners" is a sentence that could mean almost anything. "We do not sell, rent, or share your data with third parties" is a sentence that means something specific and checkable.
Where EduCatchUp lands on this
We'd rather be specific than reassuring. EduCatchUp only requests the Google API scopes it actually needs to function — course rosters to match absences to enrolled students, coursework and materials to generate accurate catch-up content — and each scope is documented, individually, with the specific reason it's requested. Student data is never sold or shared with third parties, and it's never used to train general AI models. When AI-generated lesson content is produced, the prompts sent to the model include course and topic context, not personally identifiable student information. School admin access is scoped strictly to their own school — there's no cross-school visibility, by design, not just by policy.
Trust, but verify
None of this is meant as a substitute for actually reading a tool's privacy policy yourself, or asking your school's IT lead to review it before rolling something out school-wide. A vendor telling you their practices are good is a starting point, not a conclusion. The checklist above is meant to make that review faster and more specific — a way to cut through the vague reassurance and get to the actual, checkable facts.
Student data deserves more scrutiny than a typical software purchase, not less. A few pointed questions before adoption — about what's collected, how it's used, and how it's protected — take a lot less time than dealing with the fallout of a tool that didn't take those questions seriously in the first place.