Trust & security
Security you can check.
Every claim on this page maps to a test that runs or a document we will show you. Where something is not built yet, it is on this page too — because a security posture you can’t verify is a slogan.
Four boundaries, enforced in the database
Not interface rules a bug could skip — properties of the database itself, identical for every client that will ever connect to it.
Teachers never see what a student said
A teacher sees that a support request exists and who owns it — never the student's answers. Enforced by database row security, not hidden by the interface: a teacher's account receives zero check-in rows, asserted by tests that fail the build if it ever changes.
Districts never see each other
Every record belongs to one district. Row-level security is enabled on every table, cross-district references are blocked by composite foreign keys inside the database, and the test suite asserts a second district reads zero rows on every table.
The kiosk holds nothing
A student's answers go straight to the server — never to the tablet's storage, the URL, or browser history. In-progress state lives at most 120 seconds, readable by nobody, then is deleted rather than archived. Walk-away, refresh, back-button and crash paths are all tested: the next student can recover nothing.
Our own operator reads no student data
The account WellSeen uses to set districts up holds zero student rows — enumerated from the database catalog by tests, so a future table that forgot the rule fails the suite. Setting up a district never requires seeing inside one.
The strongest control is what we never collect
A complete check-in is which of five words a student tapped, an optional topic from a fixed list, and whether they asked for an adult. No free text, no date of birth, no demographics, no disability status, no photos, no location — the fields do not exist, so no breach, subpoena, or curious insider can ever produce them. Our privacy policy lists exactly what is collected; the answer to most questionnaire rows is “we don’t hold it.”
- No sale of student information, ever
- No advertising, and no advertising trackers on any page
- No training AI models on student information
- No scores, rankings, risk ratings, or predictions about any student
- No facial recognition, emotion detection, or camera or microphone use
- No location tracking
- No comparing a student to their classmates
- No automated escalation — a support request goes to a person
How the service is built and run
Authentication
Staff accounts only — students never have accounts. Multi-factor authentication (authenticator app), enforced across every data path once enrolled. Single-use, hour-expiring password recovery that reveals nothing about which emails exist. No self-service sign-up: accounts exist only through district provisioning.
Authorization, in the database
Every access rule lives in the database as row security and explicit grants — identical for the web app, a script, or any future client, and unbypassable by an application bug. Anonymous connections hold zero grants. Privileged database functions are individually revoked from public access, and a catalog-driven test fails if a future one forgets.
Encryption & infrastructure
TLS for every connection in transit; encryption at rest by the database provider. Hosted in the United States (Vercel, Washington D.C. region; Supabase on AWS us-east-1). Security headers deny embedding, block content-type sniffing, and switch off camera, microphone and geolocation at the page level on the kiosk.
Accountability
Meaningful actions append an audit event — who did what, when, in which district. Support histories and audit trails are append-only: no role holds an update or delete grant on them. Audit records are treated as sensitive themselves, and record who acted — never what a student said.
Subprocessors — the complete list
Three. If this list changes, districts receive written notice first.
| Provider | Purpose | Location |
|---|---|---|
| Vercel | Application hosting | United States (Washington, D.C. region) |
| Supabase | Database and authentication | United States (AWS us-east-1, N. Virginia) |
| Resend | Transactional email to staff — names no student | United States |
Verified, not asserted
The numbers below are the suites that run on every change. Ask for a walkthrough and we will run them in front of you.
347
database authorization assertions
Run against a real database built from scratch: the teacher boundary, tenant isolation, kiosk scope, opt-out, privilege escalation attempts, and schema-wide sweeps enumerated from the catalog itself.
80
browser tests
Including a privacy suite that walks away mid-check-in, presses back, refreshes, and crashes on purpose — then asserts the next student can recover nothing and the tablet's storage is empty.
WCAG 2.1 AA
checked on every surface
Automated accessibility scans run on every page in the test suite, and the kiosk is additionally tested for keyboard use, screen-reader announcements, 200% text size, and timing extensions.
0
student fields added without review
Every field that touches a student clears privacy, safety and security review before it exists — and a review that did not run is recorded as skipped, never as passed.
What we don’t have yet
A security page that lists no gaps is describing a product that doesn’t exist. Ours, today:
- No SOC 2 report and no third-party penetration test yet. We are early, and we won’t pretend otherwise. What we offer instead, today: the test suites above run live in front of your technical staff, our written security model and threat model shared under NDA, and architecture review with your IT team as part of every pilot.
- Infrastructure-level access exists, as it does for any hosted service: our providers, and in break-glass circumstances our own engineers, can reach the database beneath the application’s access rules. Nothing technical stops that today, and we will say so in exactly those words to any district that asks. What limits it is the minimization above — there is no free text and no demographic or clinical field to see — plus audit, contract, and the district agreement’s access terms.
- Certifications are not claims we make. Nothing here is described as “FERPA certified” or “100% compliant” — no honest vendor self-certifies. We give your counsel the facts and the agreement, and answer every question in writing.
Found a vulnerability?
Tell us before anyone else, and we will take it seriously, fix it, and credit you if you want credit. Email hello@wellseenschools.com with “Security” in the subject. Good-faith research against your own demo access is welcome; student data is never in scope for testing.