How your school's data is kept separate.

Every school is a separate tenant. Each query carries the school it belongs to, applied in the database layer rather than remembered by individual screens, so a request that guesses another school’s record identifier returns nothing rather than data.

This is covered by automated tests that fail the build if a query could cross the boundary — including by listing, counting, aggregating, or supplying a different school’s identifier deliberately.

Twelve roles are defined, each a set of specific permissions rather than a rank. Beyond that, some roles are restricted by row: a parent reaches their own children, a teacher their own classes. Holding the permission to view students does not mean viewing all of them.

Fee collection, refunds, result publication, permission changes and student record edits are written to an audit trail with the person, the time and the change. Sensitive values are redacted before they are stored.

Passwords are hashed with bcrypt. Sessions are cookie-based, marked secure in production, and bound to the school they were issued for — a valid session from one school is worthless on another. Repeated failed sign-ins lock an account.

Credentials a school gives us for its own mail server are encrypted at rest and are never returned to a browser.

SchoolOS holds no ISO, SOC 2 or similar certification, and we will not imply otherwise. Postgres row-level security ships with the product as an optional hardening layer and is not enabled by default. If your IT team wants to review any of this in detail, we will walk them through it.