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
Access
- 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. Universities search the pool by graduation year, state, interests and GPA band.
- Two-step sign in for staff
- Platform staff, organization admins, counselors and recruiters must set up and confirm a code from an authenticator app.
- Demo and real data never mix
- Demo organizations and real organizations cannot see each other.
How an introduction works
One path, four steps
A university asks the student's organization for an introduction, and says why. Each step is a separate function in the database, and each checks that the step before it happened.
University01
Searches the pool
Every university is confirmed before it can search the pool, by graduation year, state, student type, interests and GPA band.
University02
Asks for an introduction
The recruiter asks the student's organization for an introduction and says why.
CBO03
Receives it first
The request goes to the student's organization first. Each student belongs to one organization, and a counselor works a caseload inside it.
Partnership04
Opens a shared channel
A partnership between an organization and a university opens a shared staff channel.
- One organization per student
- Each student belongs to one organization, and a counselor works a caseload inside it.
- Minimum group size
- A search that matches fewer than 10 students returns no results.
- Confirmation
- Every university is confirmed before it can search the pool.
- Organization first
- A request goes to the student's organization first.
- Audit
- Every read of a student profile is written to the audit log.
What we do not collect
Data kept out on purpose
- 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 no free text can be typed into it.
- Financial documents
- We do not ask for FAFSA, tax or aid documents, and our terms forbid uploading them.
- Children under 13
- No accounts for anyone under 13. A date of birth under 13 is refused wherever one is entered.
- Card numbers
- Payments run on a page hosted by Stripe. No card data is entered in or stored by the app.
The site itself
Browser and network
- 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 in the workspace
- No advertising scripts anywhere. No analytics scripts once you sign in. Our public pages count visits with Google Analytics only if you allow it. 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
Plainly
We have not completed a SOC 2 report, a HECVAT, an outside security audit or an outside accessibility 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.