Most data leaks in schools are not attacks. They are a shared login, a report that wasn't filtered, or a parent link that shows the whole class. Role-based access is the boring fix — and it only works if it is enforced where the data lives.
The roles that actually exist in a school
- Institution admin — every school, every setting, every role.
- Principal / head of school — one school, all modules.
- HOD — a department and the teachers who report into it.
- Teacher / class teacher — their classes; class teachers also handle their section's parents.
- Accountant — fees, invoices, receipts; not marks or HR files.
- HR — staff records, leave, payroll preparation; not student data.
- Transport manager — fleet, routes, riders.
- Parent — only their child. Student — only themselves.
Why 'hidden in the UI' is not access control
If a page hides a button but the underlying request still succeeds, the control is cosmetic. Access must be checked on the server for every read and write, with the tenant, the school and the role derived from the session — never from what the browser sends.
Hierarchy is part of access
Reporting lines decide who approves leave, who sees an escalated parent query and which staff a HOD can review. When the org chart is data, those rules follow it automatically; when it is a diagram in a PDF, they are enforced by memory.
A quick checklist
- No shared logins — every person has their own account.
- Every list and report is filtered by school scope on the server.
- Parent and student access is child-scoped with no override.
- Money and security actions are audited with who, what and when.
- OTP and password reset flows are rate-limited and never logged in plain text.
This is how MANEXA is built: permissions are data-driven and checked on the server, hierarchy shapes approvals and escalations, and the audit trail covers every sensitive action.