Security
The protections below are described specifically rather than in the usual reassuring generalities, so that a reviewer can ask us follow-up questions that have answers.
Last updated
Separation between schools
Every query for student records passes through a scoping layer that adds the school boundary automatically. A query that forgets to filter by school does not return another school’s students — it is refused. That matters more than it sounds, because most cross-tenant leaks in this kind of product are a single missing filter, and the point of enforcing the rule in one place is that forgetting is not sufficient to cause a breach.
We are also staging database-level enforcement underneath that, so the boundary will hold even for code that never goes through the application layer at all. It is written and tested but not yet switched on, and we would rather say so than describe it as though it were.
Access and accounts
Passwords are hashed with a modern algorithm and checked against known-breached password lists at the point they are set. Multi-factor authentication is supported and can be required. Sensitive administrative actions require re-authentication at the moment they are taken, not merely a valid session from earlier.
Who may see what is determined by role and by school. A staff member with permissions at one school does not thereby have them at another.
Audit records
Access to student records is logged — who, what, and when — and administrators can review it. Refused attempts are recorded as well as successful ones, because a pattern of refusals is the more interesting signal.
Reporting in aggregate
Where the product reports statistics about groups of students, figures describing very small groups are withheld rather than rounded, so that a number cannot be worked backwards to an individual. An automated check runs against every change and fails it if a new report skips that protection.
Deletion
Deletion removes records rather than marking them hidden. We specifically test that a later roster import cannot restore a deleted student, because reappearing after deletion is the most common way erasure quietly fails in systems that sync from an external source.
Reporting a vulnerability
Write to security@veristack.dev. We will confirm receipt, keep you updated, and we will not pursue anyone who reports a genuine issue to us in good faith and does not access more data than needed to demonstrate it.