NextChapter

Security & Privacy

How we handle data, plainly stated.

This page exists because a procurement or legal reviewer will read it before a salesperson ever talks to them. Nothing here is aspirational marketing copy — it describes what the product actually does today.

Current SOC 2 state: not yet started.We are not going to publish a fabricated “in progress, expected [date]” — there is no audit underway right now. When we begin a formal observation window, this page will say so with a real date. Silence would be worse than this honesty; a guessed date would be worse still.

The employer / candidate boundary

An employer that buys outplacement seats will never see an individual candidate's activity, grade, or whether they used the product. That boundary is in the contract, and every candidate is told about it directly.

Enforced structurally, not by convention:

  • The employer/candidate query layer computes aggregates from views that structurally cannot resolve to a person — there is no query path from the employer portal to an individual candidate row.
  • Employer aggregates only render at a minimum cell size of 10 people.
  • Numbers round to the nearest 5 below 50 seats, so month-over-month change can't isolate one person.
  • Cohorts under 20 seats report on a quarterly cadence instead of live.
  • An organization user can never determine whether anyone — including themselves — has a candidate account. No "already registered" errors, no search that returns a hit.
  • The Market Reality Grade, component grades, and detections never leave the candidate and their coach — no recruiter, employer, or admin query returns them.

Login is separated by portal

Logging into an employer, recruiter, coach, or hiring-manager portal does not log you into the candidate product, even when the same person holds both roles. Someone who is both an HR buyer and quietly job-searching on the candidate side gets fully separated sessions.

What we use today

  • Row-level access checks and role-scoped Postgres queries — every partner-facing query is written to select only what that role is permitted to see, not filtered after the fact.
  • Server-only data-access modules for anything touching candidate identity, so a client component can never accidentally receive a row it shouldn't.
  • Every individual-record view on a partner surface is logged with an actor and a reason.
  • Recruiter access to a candidate is per-introduction and consent-based, revocable at any time — never a browsable database.

Subprocessors

Vendors that process data on our behalf today:

  • Supabase — database, authentication, and file storage.
  • Vercel — application hosting.
  • Anthropic (Claude) — powers scoring, summarization, and generated content within the product.
  • Resend — transactional and confirmation email delivery.
  • PostHog — product analytics.

We do not sell candidate data, and we do not share individually identifiable candidate data with an employer client under any circumstance.

Retention and deletion

A candidate's Dossier, references, and account are retained for as long as the account is active, and remain available to the candidate as a free alumni account after any employer contract ends. A candidate can request deletion of their account and underlying data at any time; employer-side contract and compliance records (which never contain job-search activity, assessment, or engagement detail) are retained per the applicable contract term for compliance purposes.

Confidentiality for active job-seekers

A member using Confidential Search Mode never appears on any employer surface, and requires explicit per-instance consent before a recruiter can see them at all.

Questions

Enterprise procurement, security review, or DPA requests — reach us through the employer walkthrough form and mention security review in the timeline field.