How to Write a Privacy Policy for a Job Board or Recruiting Website

Most privacy policy templates assume two parties: your business and the person whose data you collect. A job board or recruiting website usually has four. There is the candidate submitting a resume, the job board platform hosting it, the employer's account holder reviewing it, and, more often than not, a third-party Applicant Tracking System (ATS) the employer has connected to actually manage the hiring pipeline. A privacy policy written as though the job board is the only place a resume lives misses most of where that resume actually goes, which is exactly the gap candidates and regulators both notice first.

Map the parties before you write a word

Start by naming who touches candidate data and in what order, because the answer changes what your policy has to disclose. A typical flow looks like this: a candidate submits a resume to a specific job posting, the job board stores it and makes it visible to the employer's account, and depending on how that employer has configured their hiring workflow, the data may then flow into a separate ATS the employer licenses independently, one your job board does not operate and often cannot see inside once the handoff happens.

Each arrow in that diagram is a place your privacy policy needs a sentence, not a shrug. "We share your information with employers" is true but incomplete if a meaningful share of employers are actually forwarding that data one step further, into a system with its own retention settings and its own separate privacy notice a candidate never sees unless you tell them to look for it.

That last row matters more than it looks. A candidate who wants a resume deleted usually contacts the job board first, since that's the account they signed up for, even when the data they're worried about has already moved into an employer's ATS. Your policy should say plainly what you can delete directly and what requires the candidate to also contact the employer, rather than implying a single deletion request reaches everywhere the data has traveled.

Resumes carry more personal data than the fields ask for

A resume or CV is a free-text document, not a structured form, and free-text documents routinely contain personal data nobody explicitly asked the candidate to provide. A graduation year reveals an approximate age. A photo, common on resumes submitted from many European and Asian markets even when a U.S.-based platform never requested one, reveals race and likely gender. A cover letter mentioning a disability accommodation request, a religious observance schedule, or past union membership discloses exactly the kind of information GDPR Article 9 classifies as a special category and CCPA classifies as sensitive personal information, both subject to tighter handling rules than an ordinary name and email address.

Most job boards never intended to collect any of that. It arrives anyway because a resume is whatever the candidate chooses to write on it, and a privacy policy that only describes the fields on your signup form is silently ignoring the actual document sitting in your database. The fix isn't to ban certain resume content, which is impractical to enforce and often out of step with hiring norms in some regions anyway. It's to say plainly in the policy that resumes may contain more personal detail than your form fields request, that this data is used only for the hiring purpose the candidate submitted it for, and that it is not used to build advertising profiles or shared outside the hiring context.

ATS integrations are a subprocessor relationship, even if you don't call them that

When an employer connects a third-party ATS (Greenhouse, Lever, Workday, iCIMS, and similar platforms are common examples), your job board is pushing candidate data to a downstream processor the same way a B2B SaaS product pushes customer data to its hosting or logging vendors. The difference is that the employer chose that vendor, not you, which makes it tempting to treat the integration as the employer's problem rather than something your own privacy policy needs to address. That reasoning does not hold up from the candidate's side: the candidate applied through your platform and has no visibility into which employers have an ATS connected and which don't.

The practical fix mirrors what a mature B2B SaaS company already does with its subprocessor list: name the categories of ATS integrations your platform supports, state clearly that connecting one is the employer's choice and configuration, and tell candidates that once their data reaches an employer's ATS, that system's own privacy notice governs it from that point forward. You don't need to maintain a live list of every ATS every employer has ever connected, since that list changes constantly and isn't fully within your control, but you do need to disclose that this kind of onward transfer happens at all and roughly what triggers it.

Searchable profiles need a separate consent from a single application

Many job boards offer two distinct product paths that get conflated in a single privacy policy far too often: applying to a specific posting, and opting into a searchable candidate database that any employer with an account can browse. These are not the same disclosure. Applying to one job is a discrete act with an obvious, bounded audience. Making a profile searchable is a standing decision to be visible to every current and future employer using the platform, an audience the candidate cannot fully anticipate at the moment they opt in.

Treat these as separate consent points in both your product and your policy. A candidate who applies to three specific roles should not discover later that their resume was also sitting in a searchable database they never explicitly opted into, and the policy should describe search-database visibility as an optional, separately controlled setting rather than folding it into a single blanket "we make your profile available to employers" sentence that covers both behaviors without distinguishing them.

Retention: rejected applications and talent pools

Recruiting data has an unusually predictable end-of-purpose moment, a specific hiring decision, which makes vague "as long as necessary" retention language look especially thin next to it. Once a role is filled, the resumes of candidates who weren't hired no longer serve the purpose they were collected for, unless the candidate has separately agreed to be kept in a talent pool for future roles.

That talent-pool use case is common and legitimate, but it needs its own legal basis and its own disclosure, not an assumption that rejection-stage data can be held indefinitely under the original application's consent. State a retention period for unsuccessful applications (six to twelve months is a common range, though local employment law sometimes sets a floor, particularly where discrimination claims have a statutory filing window), state separately that talent-pool retention requires an additional opt-in, and give candidates a way to ask to be removed from a talent pool without needing to withdraw a currently active application.

Automated screening deserves its own sentence

If your platform, or an ATS an employer connects, runs resumes through keyword matching, scoring, or ranking before a human reviewer sees them, that's automated processing with a real effect on the candidate's opportunity, the kind of thing GDPR Article 22 specifically addresses when a decision is made without meaningful human involvement. Most recruiting platforms keep a human in the loop at some stage, which changes the legal analysis, but the policy should still say plainly whether automated screening happens, what it's based on (keyword matching against the posting, not inferred characteristics), and that a human reviews outcomes before a final rejection is communicated. Silence here reads to a candidate, and to a regulator, as though there's something being hidden rather than something ordinary being left unstated.

Building the policy around this flow

The throughline across all of this is that a job board's privacy policy has to describe a four-party flow, candidate, platform, employer account, and often a connected ATS, instead of the two-party template most generators start from by default. Our Privacy Policy Generator lets you describe exactly this kind of multi-party data sharing, including third-party integrations and employer-visible data, so the resulting policy names the actual flow a candidate's resume travels through instead of a generic "we share data with our partners" placeholder that leaves the real question, which partners, and why, unanswered.

The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.