A Student-Data Security Checklist for Edtech Teams
July 8, 2026 · 6 min read
Start with who can see a guardian relationship
Before firewalls, before encryption diagrams, answer one question: in your platform, who can see that this student is linked to this parent? If the answer is "any teacher" or "I'm not sure," you have a student-data problem that no amount of infrastructure will fix. Access design is where student-data security actually lives.
The Canvas breach that a lot of edtech teams watched wasn't a clever attack. It was a basic access mistake that scaled, which is the point: the damage in education data rarely comes from a movie-style hack. It comes from the wrong person being able to see the wrong record, at scale, because the permission model was never designed for the sensitivity of what it holds. Student data is regulated for a reason, and in the US that reason has a name: FERPA. (The US Department of Education's FERPA overview)
The checklist, in order of what actually gets breached
- Model the relationships first. Student, guardian, teacher, and admin are not the same permission shape. A parent sees their child. A teacher sees their class. Neither should see the whole institution by default.
- Default to least privilege. New roles get the minimum, and access is granted up, not stripped down. It's much easier to add a permission than to discover you gave one away.
- Separate "can act" from "can see." An admin who can reset a password shouldn't automatically be able to read every student's records. Split the sensitive read from the routine action.
- Log the sensitive reads. An audit trail that records who viewed a guardian relationship or a grade history is what makes an incident investigable. Without it, "we're not sure who saw what" is the honest answer, and it's the worst one.
- Plan retention and deletion. Decide what expires, what archives, and who owns that decision. Data you no longer need is data that can only hurt you.
- Test the boundaries, not just the happy path. The real test is trying to see a record you shouldn't, as each role, and confirming you can't.
| Layer | The question | Bad answer |
|---|---|---|
| Roles | Who sees a guardian link? | "Any staff member" |
| Privilege | What does a new role start with? | "Everything, we trim later" |
| Audit | Who read this record? | "We don't log reads" |
| Retention | When does this data leave? | "It never does" |
The uncomfortable part
Good access control is invisible when it works and career-defining when it doesn't. It's also unglamorous, which is exactly why it gets skipped for a nicer dashboard. I'd rather ship a plainer interface with a permission model I can defend than a beautiful one where a parent can stumble into another family's data.
For the incident that makes this concrete, read the lesson from the Canvas breach. For the identity layer that decides who someone even is, see SSO options for learning platforms. When the platform holds student records, school and student portal development designs these boundaries before the first screen, and a Canvas alternative you control exists partly for teams that need that control in their own hands.
Written by Choaib Mouhrach
Founder & Senior Software Engineer
I design and build custom learning platforms for organizations with complex training and certification workflows. Instead of stitching together plugins and third-party tools, I create systems tailored to how each business operates, reducing administrative overhead while improving the learner experience.
Your learning product deserves its own platform.
If you want to deliver a learning experience built around your product, your learners, and your goals, you are in the right place. We build platforms that give you the control and flexibility to grow without limits.