Security

• In transit: every connection to northassay.com is TLS-encrypted. Plain HTTP is permanently redirected to HTTPS, and we send HSTS so a browser that has seen us once will not attempt an insecure connection again.
• At rest: the application database and object storage are both encrypted at rest by the underlying provider (Supabase for PostgreSQL, Cloudflare R2 for objects), using AES-256.
• In use by AI providers: requests to model providers travel over TLS. Content sent for generation or scoring is not retained by the provider for training — see §07.
• Credentials: we never see or store your password. Authentication is handled by Clerk, including password hashing, OAuth, and session management.

Authorization is enforced in more than one place on purpose, because a single check is a single point of failure.

• Role-based access. Every account carries a role — recruiter, candidate, or admin — in its session claims. Recruiter screens refuse a candidate; admin screens refuse a recruiter.
• Defence in depth on every protected route. Requests are filtered at the edge, and every protected page independently re-checks the session when it renders. Middleware is treated as a filter, not as the security boundary, and we have a test that fails the build if a protected page relies on it alone.
• Per-recruiter scoping. Assessment data is scoped to the account that owns it at the query layer. A recruiter cannot read another recruiter's agents, candidates, or submissions.
• Server-side authorization on every mutation. Each server action re-verifies the caller and their ownership of the record. Authorization is never inferred from the fact that a page rendered.
• Secrets stay server-side. Storage credentials, the database URL, and API keys are server-only environment variables and are never included in a browser bundle.

Video recordings and identity photos are the most sensitive data in the product, so they are handled differently from database rows.

• The object storage bucket is fully private. There is no public read access and no public URL for any object in it.
• Every read and write goes through a short-lived signed URL issued by our server only after it has authorized the request. A leaked URL expires; a guessed key does not work.
• Uploads go directly from the browser to storage using one of those signed URLs, so recordings do not transit our application servers.
• Objects are keyed per submission, so no listing operation is needed to serve one, and one candidate's key gives no access to another's.

• A direct invitation produces a private, single-purpose link bound to the email address it was sent to, with an expiry. It cannot be used after it expires.
• Invitation links in email are built from a trusted configured origin, never from the incoming request's host header, so a poisoned request cannot redirect a candidate's private link to another domain.
• Open links and access codes are an explicit recruiter choice, and the product marks results reached that way as self-asserted identity. Access-code attempts are rate-limited, and repeated or duplicated joins are flagged to the recruiter as advisory context.
• Assessment pages are excluded from search engine indexing.

Production data is in a separate database project from development and preview environments, so no engineer running the app locally is connected to production data. The full subprocessor list, with what each one processes, is in §08 of the privacy policy.

• AI output is validated before it is stored. Every model response is parsed against a schema before it reaches the database, so a malformed or unexpected response fails closed rather than being persisted.
• No raw HTML from user or model content. The interface renders text as text. Content interpolated into outbound email is escaped.
• Parameterized database access throughout, via a query builder — no string-concatenated SQL.
• Rate limiting on shared-link access codes and on public form submissions.
• Automated tests as a control, not just as QA. Route authorization has a test that walks the whole application tree and fails if any page is neither protected nor explicitly recorded as public, so a new page cannot be shipped unclassified.

• No training on your data. Role descriptions, rubrics, candidate answers, transcripts, and scores are sent to a model provider as the input to a single request, under terms that exclude training on submitted content. They are not used to train or fine-tune any model, ours or a provider's.
• Video interviews run over a real-time session with the model provider for the duration of the interview. The recording is stored in our private bucket; the transcript is stored with the submission.
• Provider is configurable. Google is in use today, with Anthropic and OpenAI also supported. A change of provider is a change of subprocessor and we will update the privacy policy when one happens.

Identity photos are deleted automatically after 30 days. Assessment answers, scores, transcripts, and recordings are retained for as long as the recruiter's account holds them, and there is no automated expiry on them today — §06 of the privacy policy explains why we are saying that rather than publishing a schedule nothing enforces. Deletion on request is available to both recruiters and candidates.

Database backups are handled by our database provider on its managed schedule. We do not currently offer a recovery-time or recovery-point objective, and NorthAssay carries no uptime commitment during early access. If continuity guarantees are a requirement for you, tell us before you build a hiring process on it.

A security page that lists only strengths is not useful to you. NorthAssay is an early-access product built by a small team, and these are the controls a mature vendor would have that we do not. If one of them is a hard requirement, we would rather you find out here than three weeks into a procurement process.

• No SOC 2, ISO 27001, or other third-party security certification, and none in progress.
• No independent penetration test and no bug bounty programme.
• No SSO/SAML, no SCIM provisioning, and no enforced multi-factor authentication policy for accounts — though our authentication provider supports MFA and you can enable it on your own account.
• No customer-visible audit log of who viewed a candidate's data.
• No role granularity within a recruiter account, and no shared workspaces — every recruiter account is independent.
• No data residency options. Everything runs in the United States.
• A Content Security Policy is not yet enforced. It is being introduced in report-only mode first, because enforcing one that has only been validated on page loads would break live video interviews.
• No uptime SLA, and no formally documented incident response plan or breach notification timeline beyond what the law requires of us.

If you have found a security issue, email hello@northassay.com with "security" in the subject. Tell us what you found and how to reproduce it. We will acknowledge you within three business days and keep you updated until it is resolved.

We will not pursue legal action against you for research conducted in good faith: staying within your own test accounts, not accessing or retaining anyone else's data, not degrading the service, and giving us a reasonable chance to fix the issue before disclosing it. We do not pay bounties yet, and we will credit you if you would like us to.

We do not have a data processing agreement published as a standard document yet. We will sign yours, or provide one on request, and we will complete a security questionnaire — write to hello@northassay.com. Where a question touches something in §10, the answer will be the same "not yet" you have already read here.