Web-based student information system: hosting, access, and who can see a child's record

"Web-based" used to mean something. When the alternative was a program installed on the office machine with the database on a server in a cupboard, a web-based student information system was a meaningful category. Today essentially every product is browser-delivered, so the phrase no longer separates anything, and the questions it used to answer have moved.

Those questions are still worth asking, and they are now three different ones: where does it run, who can see a child's record, and what happens to that record afterwards. This is the honest version of each, plus what changes if you decide to build.

Three hosting shapes

Vendor-hosted (SaaS). The supplier runs everything. You get a URL and an invoice. This is what most schools now buy and for most schools it is correct — the alternative requires someone whose job is keeping a database patched, and in a school that person usually has thirty other jobs.

What to establish before signing: where the data physically resides, who at the supplier can access production, whether that access is logged, what the exit looks like, and what happens to your records if you stop paying. That last one is not hypothetical — a school that cannot afford renewal still has statutory retention obligations.

Self-hosted. You run it, usually an open-source system, on your own infrastructure or a server you rent. The licence is free; the operation is not. Patching, backups, restore testing, uptime during term, and someone reachable when it breaks at 8:30am on results day.

Genuinely right when you have real IT capacity, a data-residency requirement you cannot otherwise meet, or a customisation need no vendor will service. Genuinely wrong — and quietly dangerous — when nobody owns it, because an unpatched system holding children's records is a worse outcome than any subscription.

Hosted-for-you open source. A third party runs an open-source system on your behalf. It splits the difference: you keep the option to take the software elsewhere, somebody else keeps it running. Worth asking about far more often than it is.

The honest summary: the hosting decision is really a staffing decision. Ask who is on call in August, and the answer tells you which shape you can actually support.

Who can see a child's record

This is the part that deserves the most attention and reliably gets the least. A school system's permission model is not an administrative nicety — it is the product.

The roles are not a hierarchy, which is where naive implementations go wrong:

A class teacher should see their own pupils, in depth, and other pupils barely at all.
A form tutor or head of year sees a wider set, but not the whole school.
A safeguarding lead sees things a class teacher must not, including records other senior staff cannot see. This is the case that breaks any design where permissions run from "less" to "more" along a single line.
The office sees contact and fee information across the school, and typically not attainment.
A parent sees their own children — and only the ones they have rights to, which is not the same as the ones they are related to.
A pupil, in many jurisdictions, has rights over their own record from a certain age.
Supply and temporary staff need a register and nothing else, and their access has to end.
Governors and trustees need aggregate figures, never individual records.
The vendor's support team — the role nobody puts on the diagram, and the one practitioners raise most often.

The design consequence: permissions are a matrix, not a ladder. Any system where an administrator role is defined as "everything a teacher can do, plus more" cannot express the safeguarding case, and will end up with someone reading something they should not.

The test, in any demo: sign in as a class teacher and try to open a pupil from a different class by URL. Then ask to see a safeguarding note as a senior leader who should not have it. A product that treats the second question as unusual has not built for schools.

Vendor access is a real question, not a paranoid one

Ask directly: can your support staff see production data, do they need approval, is it logged, and can we see that log? Some suppliers have excellent answers. The point is that it is answerable, and that a supplier who is surprised by the question is telling you something.

What breaks specifically in browser-delivered school software

The parent portal on a phone. It is where most parent contact now happens and it is consistently the last thing built and the least tested. A parent with two children in different year groups is the case that finds the bugs.
Shared classroom machines. A teacher who does not sign out leaves a session open to thirty pupils. Session timeout is a safeguarding control in a school in a way it is not in an office, and it is usually set to an office default.
Term-time load spikes. Report card publication day is the highest-traffic hour of the school year, and it is the hour every parent tries at once. Ask what happened last time.
Connectivity in the building. School Wi-Fi in a 1960s block with thick walls is not office Wi-Fi. If registers can only be taken online and the signal fails in the science block, you have bought a paper process with extra steps.
Data retention after a pupil leaves. Statutory retention periods are long, and a browser-delivered system makes the question easy to defer — the record is still there, so nobody thinks about it. Ask what happens at the end of the retention period, and whether anything can be deleted at all.
Migration in and migration out. Covered below, and underestimated in both directions.

What has to talk to what

A student information system is never alone in a school, and the integration list is where browser-delivered systems genuinely do change the answer — because integration stops being a file on a shared drive and starts being an account with permissions.

Finance. Fees collected in the SIS have to reach whatever the bursar reconciles in. Ask whether that is a real export in the format the finance system ingests, or a CSV somebody retypes.
Payments. Taking fees online means a payment provider, and the reconciliation question is the one that matters: when a parent pays, does the ledger entry appear against the right child and the right invoice automatically, or does somebody match it by hand every week?
The LMS. If you run both, define the handoff explicitly — usually enrolment flows one way and attainment flows back. Two systems that both believe they own the class list will disagree within a term.
Statutory returns. Whatever your jurisdiction requires. This is the integration schools cannot opt out of and the one most likely to be quoted as a paid add-on after purchase. Ask about it before signing, by name.
Communications. Email and SMS to guardians, which inherits the entire guardian-rights problem: the system must send to the contacts entitled to receive that message, not to everyone attached to the child.
Identity. If the school already runs a directory, staff should not have another password. Single sign-on for staff is reasonable to expect; for parents it usually is not, and that is fine.
Timetabling. Often a separate specialist product, and the integration is usually a periodic import rather than anything live.

The useful question for each: is this a supported integration, a paid add-on, or an export somebody retypes? All three are legitimate answers. Only one of them is free, and vendors are not always quick to say which you are getting.

Uptime, support, and the school calendar

Software support is usually sold on an office calendar and schools do not run on one. Two questions worth asking that rarely appear on a checklist:

What does support look like at 8:30am in September? The first week of term is when a school system is under most stress and least tolerant of a ticket queue. A supplier whose support is excellent in February and unreachable in the first week of term is a bad fit regardless of the feature list.

When do you deploy changes? An update pushed at 9am on a school day is a different proposition from one pushed to an office product. Ask whether releases avoid term-time mornings, whether you are told in advance, and whether you can defer.

Neither question is about technology. Both are about whether the supplier has schools as customers or merely as a market.

Migration is a phase, not a weekend

Every serious implementation guide in this market treats data migration as a dedicated project phase. Schools that treat it as a task are the ones still reconciling records at half term.

The specific failure practitioners describe most is guardian data landing in the wrong contact model — imported into a shape that cannot express two guardians with different rights, or one guardian across two children — and quietly breaking reporting for a term before anybody notices.

Three things worth insisting on:

Validation errors are logged and visible, not silently swallowed. An import that reports success while dropping rows is worse than one that fails loudly.
A dry run against real data before the real run, with a report of what would have changed.
A rollback plan. Not a hypothetical one — an actual answer to "we ran this and it was wrong".

And ask the exit question at the start: what does a full export look like, in what format, and does it include the historical records rather than only current pupils?

If you build one

A school system is a realistic build now — three complete ones, admissions through fees, have been built from our own school planner by different methods and run as live demos. But it is one of the less forgiving verticals to build, for reasons that have nothing to do with feature count.

The parent portal is the hard part, not the admin screens. Admin screens are CRUD and an agent will produce them competently. The parent portal is where isolation, mobile behaviour and the multi-child case all meet, and it is where a generic build is weakest because it is furthest from the training data.

Isolation must be proved in both directions. One parent must not reach another's child — and the owning parent must actually see their own children, or an empty result for everybody looks identical to working isolation. Use a control. This is the single most common way a security check gives a false pass.

Permissions belong on the server. Hiding a menu item is a convenience. Every restricted route has to refuse the request underneath, and a supply teacher pasting in a URL is a realistic threat model in a building full of shared devices.

Academic year and annual promotion are first-class. They are missing from nearly every generic build, because nothing in "build a school management system" says the year rolls over.

Guardians are their own entity with rights attached to the relationship. Not a text field. This is not retrofittable and it is the decision that determines whether the parent portal is possible.

Across the build-offs we have run in other markets — ten of them, forty-eight audited applications — the pattern is consistent and it applies here with more force than anywhere else: capable models produce the visible features and miss the substrate. In most verticals that means a broken report. In a school system it means a person seeing a child's record who should not, and that is a different category of failure.

So which should you choose?

Vendor-hosted is right for most schools, most of the time. Buy it, and spend the evaluation effort on the permission model and the exit terms rather than on the feature grid.

Self-hosted is right when you have genuine IT capacity or a hard data-residency requirement, and wrong the moment nobody is clearly accountable for patching it.

Hosted open source is the underrated middle, particularly for small groups of schools who can share the cost of somebody competent.

Build is right when your institution subtype genuinely is not served — a coaching centre being sold a K-12 product, a boarding school, an unusual fee model — and when you are prepared to specify the permission matrix and the guardian model rather than hope they appear.

The question was never really whether a student information system is web-based. They all are. The question is who can see a child's record, and whether anyone has tested it.

If the question is scope rather than architecture, student information system has the counted list from 46 real school systems, the SIS-versus-LMS distinction, and the guardian model in more detail. What a school management system includes and build vs buy cover the rest of the decision.

And if you are building, the School Management planner is the specification we hand our own agents — institution subtype locked first, the role and permission matrix written before any screen, and migration treated as a phase with its own gates.