Who Should See What in School Software

A school holds more sensitive data than it thinks

Ask a principal what confidential information the school holds and the answer usually starts with exam papers. It should start with the students.

A school's records include children's home addresses, guardian phone numbers, dates of birth, medical notes, family circumstances recorded during admission, academic performance, and attendance patterns that reveal a good deal about a family's situation. Much of it is exactly the information you would not want circulating, and all of it sits in the same system that staff use for routine daily tasks.

This is not usually neglected out of indifference. It is neglected because access control feels like an IT concern, and because the immediate cost of getting it wrong is invisible while the immediate cost of getting it too tight — a teacher who cannot do their job — is loud and instant.

Both failure directions are real

Access control discussions tend to assume the only risk is too much access. In schools the opposite failure is at least as common and does more day-to-day damage.

Too much access means every staff member can see every student's full record. Usually nothing happens. Occasionally something does, and when it does it is serious and hard to explain afterwards — a home address reaching someone it should not, a medical note discussed in a staff room, a family circumstance becoming general knowledge.

Too little access means a class teacher cannot see their own section's contact numbers without asking the office. This does not produce an incident; it produces a workaround. The teacher keeps their own list. So does everyone else. Within a term the school has a dozen private spreadsheets of student contact data on personal devices, entirely outside whatever controls the main system has — which is a far worse position than the one the restriction was meant to prevent.

The second failure is more common precisely because it looks like caution. A system nobody can work in does not get used carefully; it gets bypassed.

Start from the task, not from the data

The usual approach to permissions is to list the data and decide who may see each category. This produces long matrices that are hard to reason about and harder to maintain.

Working from tasks is more tractable. For each role, write down what that person actually does in a week, then grant what those tasks require:

• A class teacher marks their section's attendance, enters marks for the subjects they teach, and contacts parents of students in their section. That requires full records for their own section, subject-level access for their teaching classes, and nothing across the rest of the school.
• An exam coordinator configures assessment structures, monitors marks entry coverage, and generates results. That requires the exam configuration and marks across all classes — but little need for guardian contact details or admission-time family notes.
• Office and admissions staff process enquiries, maintain student records, upload documents, and answer parent queries. That requires broad access to student and guardian data, and generally no need to enter marks.
• Leadership needs the summary across everything — attendance trends, results, admissions pipeline — which is mostly aggregate rather than individual, and is a genuinely different shape of access from the roles above.

Written this way, the permissions fall out of the job description, which is also what makes them defensible when someone asks why a particular person can see a particular thing.

Make access a property of the role

The most important structural decision is that permissions attach to roles rather than to individuals.

Per-person permissions feel flexible and decay reliably. Someone covers a colleague's class for a fortnight and is granted access that is never removed. A teacher takes on exam duties one year and keeps the coordinator's view for the next three. Nobody is careless; there is simply no moment at which anyone is prompted to revoke anything, because the grant was an exception and exceptions are not reviewed.

Role-based access removes the problem structurally rather than relying on someone remembering. A person's access is whatever their role grants. Change the role and the access changes with it. Onboarding a new teacher becomes creating the record and assigning their classes, not configuring permissions by hand — and, importantly, a member of staff leaving is one change rather than an audit of everything they might have been granted over five years.

Watch the four places controls quietly leak

Well-designed permissions are commonly undone by four ordinary things.

• Exports. Access controls govern the screen, not the spreadsheet someone downloads from it. A restricted view exported to a file and emailed onward has no restrictions at all. This is worth an explicit school policy, because no software setting solves it.
• Shared logins. One office account used by three people destroys both access control and any ability to know who did what. It usually starts as a convenience during a busy week and never gets undone.
• Reports. A report can aggregate data from areas the person running it cannot open directly. Reporting needs its own permissions, thought about separately, or it becomes a side door.
• Assistive and search features. Anything that answers questions across the school's data — including an AI assistant — must answer only from what the asking person's role already permits. A feature that helpfully surfaces information the user could not otherwise reach is a permission bypass wearing a friendlier interface.

That last one is worth checking specifically when evaluating any system that offers conversational or cross-record search. The right behaviour is that the assistant is bounded by the same role permissions as every other screen.

Review it once a year, when the session turns

Permissions drift. Roles change, responsibilities move between staff, and people leave.

The natural moment to review is the session boundary, when class teachers and subject assignments are being reset anyway. Walk the staff list, confirm each person's role still matches what they do, and confirm that everyone on the list still works at the school. It takes an afternoon and it is the only reliable defence against the slow accumulation that makes a well-designed permission model meaningless after three years.

If you want to see how this is handled structurally, staff and roles in e-SchoolBase assigns office, teaching and leadership staff different views of the same system, with the AI assistant bounded by the same role permissions rather than sitting outside them.