Trust & Data Posture

No. We will not claim a certification we have not earned. SOC 2 Type II is on our roadmap and we will publish the date the day the audit completes. Until then, the controls we already operate (encryption in transit and at rest, row-level security on multi-tenant tables, least-privilege admin access, and a sub-processor list published here rather than behind a request form) are listed below in plain language, with no badge attached to them.

Yes, in the substantive sense that matters: every JobCannon user has the right to export their data, the right to deletion, and the right to a copy of any record we hold about them. We act on those requests within the GDPR-mandated 30-day window, and account deletion actually runs during the request itself. Where we are not yet finished: a formal Data Processing Agreement has been drafted against our real infrastructure and is with legal review as of September 2026 — it is not signature-ready, and until it is we would rather tell you that than send you a document nobody has reviewed. Contact support@jobcannon.io and we will tell you where it stands against your procurement timeline. We do not display a GDPR badge because no enforcement body issues one; we display the underlying controls instead.

Application data — accounts, assessment results, organizational tenancy — is stored in Supabase's managed Postgres on AWS in Ireland (eu-west-1). There is one region: it is not a per-tenant choice and there is no US or APAC alternative to switch to. Read that as a statement about the primary datastore and not about every byte, because it is not the same claim: hosting and edge cache, email delivery, queueing, analytics and the LLM inference behind generated narratives all run through vendors outside the EU. They are named one by one in the sub-processor table on this page. Payment data never touches our servers — it goes directly to Stripe.

Sixteen, as at 20 September 2026 — and this page listed five until we audited the production environment against the code instead of against our own copy. The full table with purpose and location for each is on this page, above; we do not keep it behind a request form. In short: Supabase and AWS hold the application database in Ireland; Vercel and Cloudflare serve and protect the application; Stripe sees billing data and never assessment data; Resend delivers transactional email and Upstash queues it; Google (Gemini via Vertex AI) and Groq run the model inference behind generated narratives, and those prompts contain assessment scores, so "anonymized prompts" — which this answer used to say — was wrong; Microsoft Clarity, Google Analytics 4, Ahrefs and HubSpot cover product analytics and CRM; Google One Tap handles federated sign-in; Meta receives server-side conversion events for consumer advertising measurement, never for a candidate who arrives through an employer invitation or a class code; and Telegram receives our own operational error alerts, which can carry the email address of the user an error affected.

No — by deliberate design. In institutional deployments, coordinators see aggregate cohort metrics (archetype distribution, completion rates, skill-gap rollups) by default. Individual candidate summaries (archetype label, top career matches) are visible to coordinators only when the candidate explicitly consents during the assessment. Raw item-level answers are never exposed to any administrator in any tier. Two layers hold that, and it is worth knowing which is which, because this answer used to credit only the stronger one: multi-tenant tables carry row-level security policies enforced by Postgres itself, and the server-side routes behind the admin dashboard run with a service role that bypasses those policies by design — on those paths isolation is enforced by the queries, which never select raw answers into an admin-facing response. The database layer is real. It is not the only thing standing between an application bug and a leak.

No. We do not train any model on customer assessment data, organization data, or cohort data, and we have no model of our own to train. The AI-generated content surfaces (premium narratives, career-explanation engine, coach-style framing) call third-party models at request time: Google's Gemini models through Vertex AI on Google Cloud, with Groq as a fallback when that is unavailable, both under standard commercial terms that exclude training-data use of prompts. One correction to what this page said before: the prompts are not anonymized. They carry the assessment scores and the result label, which is assessment data, and describing it otherwise made a weaker control sound like a stronger one.

A candidate deletion request removes the user record, the assessment results, the answers, and the user's presence in any cohort. It is not a 30-day queue, which is what this page used to promise: the erase routine runs inside the request, and by the time the call returns the rows are gone — it then re-checks that nothing keyed to that account survived and alerts us if anything did. Aggregate cohort metrics that depended on that user's presence remain (the rollup numbers do not retroactively change), but the user-level data is gone. An organization deletion removes the org tenancy, all cohorts under it, and all org-scoped data. Backups are the one exception, and the real number is smaller than the one we used to publish: the managed database keeps daily backups for 7 days, with point-in-time recovery not enabled (measured 20 September 2026). Data inside an existing backup cannot be selectively erased — it ages out with the backup.

The honest answer is narrower than the usual vendor answer, so read it slowly. For U.S. K-12 partners we operate a school-official posture consistent with FERPA: institutional deployments restrict who sees what student data, and deletion is available on request. What does not exist yet is the paperwork — we do not have a written school-district agreement drafted and waiting, and our Data Processing Agreement is still in legal review, so both are negotiated as part of a district engagement rather than signed off a shelf. On COPPA our posture is data minimisation, not parental consent: on a class code we collect no email address and no demographics, a student enters a code and picks a username, and the production surface carries no third-party advertising trackers for them. We do NOT have a verifiable-parental-consent workflow for under-13s — if your district requires one, that requirement is unmet today, and our /for-school-districts page says the same thing. Our guides on /b2b/guides/ferpa-student-data-career-platform and /b2b/guides/coppa-compliance-career-assessment-under-13 walk school administrators through the rest of the posture.

Not today — and this answer said "yes" until we checked the live setting instead of the code. SAML 2.0 is switched off on our authentication project (verified against production, not inferred: the admin endpoint answers cheerfully with an empty list whether SAML is on or off, and the setting that actually decides it reads disabled). So no identity-provider connection would work if we tried to stand one up for you tonight, whoever your IdP is. Turning it on is a project-level configuration change that moves us onto per-SSO-user billing; we will make it for a district or enterprise engagement that needs it, so contact support@jobcannon.io with your identity provider and the domain your team signs in with and we will give you a date rather than a maybe. What works today is Google sign-in, including Google Workspace for Education accounts. Background in our /b2b/guides/saml-sso-career-assessment-platform guide.

Notification within 72 hours for any incident affecting customer data, consistent with GDPR Article 33. Notification goes to the listed billing contact on the affected organization and, where required, to the relevant supervisory authority. A post-incident report (root cause, scope, remediation, prevention) is published within 30 days to the affected customer. We have not had an incident requiring such notification to date; if and when one occurs, we will say so on this page.

Not yet, and this page promised one by default until today. A DPA covering GDPR Article 28 processor obligations — sub-processor list and notification of changes, data-export and deletion mechanics, the security controls, international transfers — has been drafted against our actual infrastructure rather than against our marketing copy, and it is with legal review as of September 2026. It is not signature-ready, and we will not send a procurement team a compliance document that no lawyer has read. Contact support@jobcannon.io and we will tell you exactly where it stands and what it means for your timeline. Once it is through review it is included with Team, Scale, and Enterprise.