Security
Student records are protected by rules in the database, not by promises in a handbook.
This page lists the controls that are in the product today. It does not list certifications, because we do not hold any yet.
Who can read what
- Row level security on every table
- The database checks each request against the signed-in person before it returns a row. A bug in a screen cannot skip that check.
- The organization is the boundary
- Staff see records in their own organization. One CBO cannot read another CBO's students.
- Universities cannot read student records
- No rule in the database gives a university member access to a student's record. They see a de-identified block until a release exists.
- Two-step sign in for staff
- Platform staff, organization admins, counselors and recruiters confirm a code from an authenticator app.
- Demo and real data never mix
- Demo organizations and real organizations cannot see each other.
How identity is released
One path, four steps
There is one way for a university to learn who a student is. Each step is a separate function in the database, and each checks that the step before it happened.
University01
Asks for an introduction
A recruiter finds a profile with no name on it and sends a request that says why they are asking.
CBO02
Decides first
Staff who know the student approve or decline. A declined request ends here and the family is never asked.
Student or guardian03
Gives consent
An adult student decides for themselves. For a minor, the guardian decides. Staff cannot answer for a family.
Release04
Identity is shared
The university can now read the profile. Every read is logged. Access ends after 12 months or the moment it is revoked.
- Consent to be listed
- A profile can be listed in the pool only with a recorded share consent. Staff cannot give that consent for a family.
- Minimum group size
- A search that matches fewer than 10 students returns no results.
- Revocation
- Revoking a release ends access at once.
- Expiry
- Releases expire after 12 months.
- Audit
- Every read of a released profile is written to the audit log.
What we do not collect
- Protected traits
- No fields or filters for race, ethnicity, nationality, ancestry, immigration status, disability or justice involvement.
- Free text in shared profiles
- The block a university sees has fixed fields only, so nothing identifying can be typed into it.
- Financial documents
- We never accept FAFSA, tax or aid documents.
- Children under 13
- No accounts for anyone under 13.
- Card numbers
- Payments run on a page hosted by Stripe. No card data is entered in or stored by the app.
The site itself
- Strict content security policy
- Each page is served with a fresh nonce, so only scripts the server approved for that request can run. The site cannot be framed by another site.
- Transport and browser headers
- HSTS, no content type sniffing, a referrer policy and a permissions policy are set on every response.
- No ads, no trackers
- No advertising or analytics scripts. Fonts are served from our own domain.
- Bot protection on public forms
- Public forms use a hidden trap field, rate limits and, where it is turned on, Google reCAPTCHA.
- Secrets
- Keys live in the hosting environment and are never committed to code.
What we do not claim
We have not completed a SOC 2 report, a HECVAT or an outside audit. When we do, it will be stated here with a date.
We do not sell student data and we do not use it for advertising. The privacy policy says the same thing in more detail.
See the controls from the inside.
The demo runs on fictional data in organizations that are walled off from real ones.