What we protect, and how.
A hiring platform holds sensitive things: who you are, where you have worked, what a company pays. This page says what we do about that — in the same plain language as the rest of the site, claiming nothing we have not built.
The short version
We hold what the product needs and refuse the rest. Identity verification stores a result, never your ID document or selfie — those stay with the verification vendor, in its own flow. Card numbers never touch our servers — cards are entered only on Stripe’s hosted pages, and we store a reference, not a card. Screening is blind by construction: an employer reads work, not names. And there are no ads, no analytics trackers, and no data sales — the site loads no advertising or analytics script from anyone, and our Content-Security-Policy is written to keep it that way.
Our controls
- Encryption everywhere it travels and rests. TLS on every connection (with HSTS, so browsers refuse to downgrade); encryption at rest on the database and file layers our vendors run.
- Row-level access rules on every table, default deny. The database itself enforces who can read what — a candidate’s row, an employer’s row — rather than trusting application code to remember. Server credentials never ship to the browser, and secrets live in managed secret stores, never in code.
- Every action authorization-checked. Each server operation re-verifies who is asking and what they are allowed to touch. We review our own actions and data paths adversarially as the product changes — most recently in September 2026 — and fix what those reviews find. Security is never finished, and we do not claim otherwise.
- Blindness enforced at the source. The screening view is composed server-side from an explicit list of fields safe to show — the database itself gives employers no direct read of a candidate’s record at all. Name, email, school, graduation year, and reference contacts are withheld until you choose to advance someone, by construction rather than by redaction — and reference contacts need the candidate’s standing permission even then.
- Access is granted per person, not per company. An employer seat opens only the parts of their own account an admin has granted it — screening, decisions, posting, hiring, their record, their team, their billing are separate grants. The money pages are enforced at the database, not merely hidden, and the organization’s own authority fields cannot be written by any client at all.
- Multi-factor authentication on the vendor consoles we administer the platform from (database, hosting, payments, DNS); two-step sign-inavailable on every account (an authenticator app, with one-time recovery codes); employer sessions sign out after twelve hours idle and every session is re-checked after thirty days; and audit logging on sensitive actions — money, moderation, and the moment a candidate’s identity is unlocked to an employer.
- Strict browser policy. Content-Security-Policy, frame-ancestors denied (no embedding this site in someone else’s), referrer trimming, and security headers on every response.
- Fraud and abuse monitoring. Duplicate-account and fake-posting signals are checked by machinery and decided by a person — nothing is auto-banned by an algorithm.
The interview panel is blind, too
Screening isn’t the only place we enforce independent judgment. When an employer’s team interviews a candidate here, each interviewer scores against the role’s own questions — and no one can see a teammate’s scores until their own card is in. That rule lives in the database’s row-level access rules, not in a setting someone can flip: the first loud opinion in the room cannot anchor the rest, because the room cannot form until everyone has written theirs down.
A submitted card locks, apart from a short author-only window for typos that ends the moment the panel opens. Opening the panel — the debrief — is itself an explicit, recorded, one-way act: it unblinds every card for the whole team at once, on the record. And when the scores come together, disagreement is surfaced, never averaged away: the rollup shows every interviewer’s mark, and a real split is flagged as the thing to talk about. The platform does the arithmetic; the judgments are written by the people in the room — no AI scores anyone.
What we deliberately never hold
Full card numbers (Stripe holds those, under PCI DSS Level 1). Your ID document or selfie (Didit processes them in its own flow; we store the outcome — verified, and over 18 — plus a session reference). Advertising profiles of any kind. If we do not hold it, it cannot leak from us.
The vendors under the floorboards
Callback runs on infrastructure from companies whose security programs are audited far more heavily than a company our size could afford — that is part of why we chose them. Each processes data under a data-protection agreement; none may sell it or use it for advertising, and Anthropic may not use it to train models.
| Vendor | Runs | Certifications they publish |
|---|---|---|
| Supabase | Database | SOC 2 Type II, ISO 27001, HIPAA, PCI |
| Vercel | Hosting | SOC 2 Type II, ISO 27001 |
| Stripe | Payments | PCI DSS Level 1, SOC 2, ISO 27001 |
| Resend | Email delivery | SOC 2 Type II |
| Didit | Identity verification | ISO 27001/27017/27018, SOC 2 Type II |
| Anthropic | Résumé parsing, interview guides | SOC 2 Type II |
| Cloudflare | DNS, email routing, the bot check on our forms | SOC 2 Type II, ISO 27001 |
When something goes wrong
We keep a written incident runbook, and the promise in our Privacy Policy is the one that governs: if a breach affects your unsecured private information, Callback Hiring LLC notifies you promptly and as the law requires — New York’s SHIELD Act sets our floor. No quiet fixes of loud problems.
Found a vulnerability?
Tell us first: hello@hirecallback.com (also listed in security.txt). Give us a reasonable window to fix it before publishing, do not access other people’s data beyond the minimum needed to demonstrate the issue, and we will not pursue legal action against good-faith security research. A person reads every report.
What we do not claim
No SOC 2 badge of our own yet — audits of that size are for a later stage of this company, and pretending otherwise would be exactly the kind of theater this site exists to replace. Our vendors carry theirs; our controls are listed above; and when an enterprise customer needs the audit, we will do the audit. Questions about any of this get a straight answer: hello@hirecallback.com.
See also the Privacy Policy, Terms of Service, Posting Standards, and Scorecard methodology.