Privacy Policy

Effective date: 5 September 2026

This policy explains what Bespoke Soft ("we", "us") does with personal data when you use Staffinit — the applicant tracking system at https://ats.staffinit.com and the website at https://staffinit.com.

1. Two different roles, and why the difference matters

Staffinit handles personal data in two distinct roles, and your rights differ depending on which one applies to you.

We are the controller for the people who hold a Staffinit account — recruiters, hiring managers, administrators — and for visitors to our website. We decide why and how that data is processed, and section 3 describes it.

We are a processor for the candidate data that a customer puts into Staffinit: CVs, applications, interview notes, screening answers, scores. The customer's organisation is the controller of that data. They decided to collect it, they decide how long to keep it, and they answer to the candidate for it. We process it on their documented instructions and for no purpose of our own. Section 4 describes it.

If you applied for a job through Staffinit and want to know what is held about you, or want it corrected or erased, the organisation you applied to is who to ask — not us. They hold the tools to export, correct and erase your record. If you contact us instead, we will pass the request to them; we will not act on their data ourselves except where the law requires it.

Self-hosted Staffinit deployments are outside this policy entirely. Staffinit's core is open-source software, and anyone can run their own instance. If you are dealing with an instance we do not operate, that operator's privacy notice applies, not this one.

2. Who we are and how to reach us

Bespoke Soft operates the hosted Staffinit service.

• Privacy questions, data-subject requests and general support: support@staffinit.com
• Security reports: security@staffinit.com (please do not use public GitHub issues)

3. Data we process as controller

3.1 Account and organisation data

Your name, email address, password hash or federated-identity link, profile settings, the organisation you belong to, your role within it, notification preferences and language. We need this to give you an account and to enforce who inside your organisation can see what.

You can sign in with an email and password, or through Google, GitHub, Microsoft or your own identity provider over OIDC/SAML. When you use a federated provider, we receive the identifiers that provider releases to us — typically your email address, name and a stable user id. We do not receive your password.

3.2 Billing data

Plan, subscription status, billing cadence, invoices and the identifiers Stripe issues for your customer and subscription records. Card numbers never reach our servers — checkout and the billing portal are hosted by Stripe, which acts as an independent controller for payment data under its own privacy policy.

3.3 Product analytics

We use PostHog to understand how the product is used. This runs on a two-tier consent model:

• Before you make a choice, and if you decline, PostHog runs cookieless. The identifier lives in your browser tab's sessionStorage and is destroyed when the tab closes. Nothing is written to a cookie or to persistent storage, so there is no cross-session and no cross-site tracking. If you are signed in you are counted against your opaque user id; your email and name are not sent.
• If you accept, the identifier is persisted so that repeat visits join up, and your email and name are attached to your profile.

Independently of your choice, we disable the invasive parts of the tool: no autocapture, no session recording, no console-log capture, no surveys. We also strip IP addresses from every event before they leave your browser ($ip and $initial_ip are on the denylist), so we do not collect location by IP for analytics. Analytics traffic is proxied through our own domain rather than sent to a third-party hostname directly.

Your choice is stored in a staffinit-consent cookie that is shared across staffinit.com and its subdomains, so you are asked once rather than on each site.

3.4 Advertising measurement

On our own hosted service only, we load Google's tag to measure whether an advertising click led to a sign-up. It runs under Google Consent Mode with ad_storage denied until you accept analytics. Self-hosted deployments load no Google tag and make no request to Google.

3.5 Support, feedback and error reports

If you email us, or send feedback from inside the product, we process what you send us. In-app feedback, where an organisation has enabled it, is filed as an issue in our GitHub repository — so do not put personal data about a candidate into a feedback message.

We capture unhandled application errors so we can fix them, through PostHog and through Sentry (EU region). An error report carries a stack trace and the path of the page or endpoint that failed — /dashboard/candidates, not ?search= and whatever was typed into it: the query string is removed from the report, from the performance events sampled alongside it, and from the breadcrumb trail leading to it, before anything is sent. Your IP address, cookies and request headers are not attached, we do not record your session, and we do not capture console logs.

3.6 Server logs and abuse prevention

Ordinary web-server records: request paths, timestamps, response codes, user agents and IP addresses. We use them to keep the service running, to enforce rate limits, and to investigate abuse and security incidents.

3.7 Legal bases (GDPR Article 6)

Where we rely on consent you can withdraw it at any time, and withdrawing it does not affect what happened before. Where we rely on legitimate interests you can object, and we will stop unless we have compelling grounds not to.

4. Data we process as processor, for our customers

When a customer's organisation runs a recruitment process in Staffinit, we process on their behalf:

• Candidate identity and contact details — name, email, phone, location, photograph where one is supplied.
• Uploaded documents — CVs, cover letters, portfolios, certificates, screening-call transcripts and anything else the organisation or the candidate uploads.
• Content extracted from those documents — work history, education, skills, and other structured fields derived from a CV, plus vector embeddings used for semantic search.
• Application data — which role, which pipeline stage, answers to screening questions, availability, asking rate, source channel, rejection or disqualification reason.
• Assessment data — AI analysis runs and their reasoning, scores, interview records and notes, recruiter comments, and the activity log of who did what and when.
• Client-contact data, for staffing agencies — the name, role, email, phone and notes of a person at a company the agency recruits for.

Categories vary because the customer decides what to ask for. If an organisation configures a question that elicits special-category data under Article 9, that is their decision and their lawful basis to establish; our terms require them to have one.

We do not use candidate data for our own purposes. We do not sell it, we do not rent it, we do not use it to build models or profiles of our own, and we do not use it to advertise.

5. Automated processing and AI

Staffinit uses large language models to read CVs, extract structured fields, summarise candidates, score them against a role, generate screening questions, analyse interview transcripts, and answer questions in the in-product assistant.

These are decision-support tools, not decision-makers. Every score is presented with the reasoning that produced it so a recruiter can check it, and every score can be overridden. Our terms require customers to keep a human in the loop and forbid using an AI score as the sole basis for a decision that produces legal or similarly significant effects on a candidate. If you are a candidate and believe a decision about you was made solely by automated means, raise it with the organisation you applied to; under Article 22 you may be entitled to human intervention.

Where the data goes. An organisation either brings its own API key for a model provider ("BYOK"), in which case its data goes to the provider it chose under the account it controls, or it uses our platform credits, in which case we route the request through OpenRouter to a model from Anthropic, OpenAI, Google or xAI. In both cases the content is sent to the provider only to produce that response and is returned to the organisation's workspace. We do not license customer content to model providers for training, and we use these providers through their APIs rather than their consumer products. An organisation can also point Staffinit at its own OpenAI-compatible endpoint, including a self-hosted model, in which case nothing leaves the infrastructure it nominates.

Vector embeddings computed for semantic search are stored in our database alongside the candidate record and are erased with it.

6. Connected Google and Microsoft accounts

Two features ask for access to an account you already have: calendar scheduling, and connecting your mailbox. They are separate connections, asked for separately, and either can be used without the other.

6.1 Calendar

If you connect a Google Calendar, we request calendar.events and userinfo.email — the narrowest scopes that do the job. We use them to create and update the interview events you schedule in Staffinit and to read back whether invitees accepted, so the recruiter can see the RSVP state. We do not read your calendar list, your settings, or events we did not create.

Google Limited Use disclosure. Staffinit's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not transfer that data except as necessary to provide the feature, we do not use it for advertising, and we do not allow humans to read it except with your explicit permission, for security purposes, to comply with the law, or on aggregated anonymised data for internal operations.

Refresh tokens for a connected calendar are encrypted at rest. Disconnecting the integration in Staffinit deletes the stored tokens; you can also revoke access from your Google account.

6.2 Connected mailboxes

If you choose to connect your mailbox to Staffinit, we read messages in it so that we can identify correspondence with candidates in your organisation and file it against the matching candidate record, and we send your replies from your own address.

If you connect a Google Workspace or Gmail mailbox, we request:

• https://www.googleapis.com/auth/gmail.readonly — to read messages in your mailbox so that we can identify correspondence with candidates in your organisation and file it against the matching candidate record. We deliberately do not request gmail.modify: nothing in Staffinit can label, archive, move or delete anything in your mailbox.
• https://www.googleapis.com/auth/gmail.send — to send replies from your address when you reply to a candidate from within Staffinit.
• https://www.googleapis.com/auth/userinfo.email — to record which address you connected.

If you connect a Microsoft 365 mailbox, we request Mail.Read and Mail.Send for the same two purposes, User.Read to record which address you connected, Calendars.ReadWrite for the calendar feature described above, and offline_access, which is what lets the connection keep working without asking you to sign in again. A tenant administrator may approve only some of these; we then switch off the capability that was not granted rather than claiming it.

There is also a third route that uses no account access at all: we can give you a private forwarding address and you point an inbox rule at it. It asks for no scopes and holds no tokens, but it does deliver us your mail, so everything below about what we keep, what we discard, and what we never do with it applies to that route in full.

We only keep mail exchanged with your candidates. Every message we read is matched against the candidate records in your organisation. If a message does not correspond to exactly one such candidate, we discard it: its content, its addresses, and its existence are not written to our database, our object storage, our search index, or our logs, and its attachments are never downloaded.

Messages we do keep are stored against that candidate, are visible only to your organisation, and are deleted when you delete the candidate or when your organisation's retention period expires.

We do not use mailbox content to create, train, or improve any artificial intelligence or machine learning model, and we do not share it with any AI or machine-learning provider. The AI features described in section 5 do not read your mail.

We do not sell mailbox content, do not use it for advertising, and do not transfer it to third parties except as necessary to provide these features, to comply with the law, or to protect against fraud or abuse. Our employees do not read it, except where you have given us documented consent to view specific messages, where the law requires it, or for security investigations.

Access and refresh tokens for a connected mailbox are encrypted at rest. You can disconnect your mailbox at any time from Settings → Integrations, which deletes the stored tokens. You can also revoke Staffinit's access from your Google account or your Microsoft account.

The use of information received from Google Workspace scopes will adhere to the Google User Data Policy, including the Limited Use requirements.

7. Email

We send transactional email — verification, password reset, invitations, notifications, and the confirmation and status emails a customer configures for candidates. Delivery is by Resend, or by an SMTP server the operator configures. Message content and recipient addresses necessarily pass through that provider.

Where a customer uses candidate messaging, replies route back through a dedicated reply subdomain so the thread lands against the right candidate record.

8. Sub-processors

The hosted service uses the providers below. Each has access only to what its function requires.

An organisation that brings its own model provider adds that provider to its own processor register; the choice is theirs, not ours.

9. International transfers

Several of the sub-processors listed above are established outside the European Economic Area, principally in the United States. Where personal data is transferred outside the EEA we rely on the European Commission's Standard Contractual Clauses, or on an adequacy decision where one applies, together with the supplementary measures the transfer requires. Analytics run on PostHog's EU region and error monitoring on Sentry's. You can ask us for details of a specific transfer at support@staffinit.com.

10. How long we keep data

Candidate data is kept for as long as the controlling organisation says. Staffinit's retention tooling deletes a candidate a configurable number of months — 24 by default — after the end of their most recent recruitment process, not after their upload date. Expired candidates first enter a recoverable quarantine, 30 days by default, and are then permanently erased: database records, uploaded files in object storage, AI analyses, interviews, transcripts, comments, custom fields and activity-log entries. A fresh application restores the candidate and resets the clock. An organisation can put a candidate on a documented legal hold that suppresses both automatic and manual erasure.

Assistant conversations are deleted after 180 days without activity, together with their messages, sources and attachments.

Account data is kept while the account exists and for a short period afterwards, then deleted.

Billing records are kept for as long as tax and accounting law requires.

Backups expire on their own rotation rather than being purged on demand, which is the standard position: an erasure removes the live record immediately, and the backup copy ages out.

Retention audit records are kept as proof that erasure happened. They deliberately contain no names, emails, filenames, CV content or storage keys.

11. Security

• Transport encryption everywhere, with HSTS.
• Third-party credentials — model-provider API keys, calendar refresh tokens — are encrypted at rest with AES-256-GCM under keys derived per purpose.
• Every query is scoped to an organisation; cross-tenant isolation is enforced in code and covered by a dedicated test suite that tries to break it.
• Passwords are hashed, never stored or logged in the clear. API keys are never logged.
• A per-request Content-Security-Policy nonce, framing and MIME-sniffing protections, and rate limiting on the API.
• Uploads are parsed in an isolated worker with resource limits, and outbound requests to customer-nominated AI endpoints are DNS-revalidated before every call to prevent them being pointed at internal networks.

No system is perfectly secure. If you find a vulnerability, please report it to security@staffinit.com; we treat good-faith research as authorised.

12. Your rights

If we are the controller of data about you, you have the right to access it, to have it corrected, to have it erased, to restrict or object to processing, to portability, and to withdraw consent. Write to support@staffinit.com. We will respond within one month and will tell you if we need longer.

If your data sits in a customer's workspace — because you applied for a job — those rights are exercised against that organisation, as explained in section 1. Staffinit gives them a per-candidate export covering the candidate record, applications, answers, interviews, scores, AI analysis runs, transcripts, comments, custom fields and activity log, and a one-click erasure that removes all of it. They do not need our involvement to answer you.

You also have the right to complain to a data protection authority in the country where you live or work.

13. Children

Staffinit is a business tool and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child's data has reached the service, tell us and we will remove it.

14. Changes

We will update this policy as the product changes. The effective date at the top always reflects the current version, and we will tell account holders about material changes before they take effect.