Holding candidate data lawfully under UK and EU GDPR

Every candidate record carries the basis you rely on, chosen from a fixed list rather than typed: consent, legitimate interests, performance of a contract, or a legal obligation. The list is short and fixed on purpose. A free-text field lets sixty recruiters describe the same basis forty different ways, and the resulting database cannot be counted, reviewed or defended.

Where the basis is consent, the record carries the channel it arrived through, the wording shown at the time, the timestamp, and the user or form that captured it. Basis changes across a record's life: a candidate sourced under legitimate interests who later replies and opts in moves to consent, and both events stay on the record rather than the first being overwritten. Withdrawal is its own dated event.

What the product will not do is pick the basis for you. Choosing between consent and legitimate interests for a sourced candidate is a controller decision with consequences, and a vendor default would be a bad answer dressed as a convenience.

Sourcing works on legitimate interests far more often than on consent, because the candidate has not been asked yet. That basis is available, and it is not a free pass. It requires an assessment that identifies the interest, tests whether the processing is necessary to it, and balances it against the rights and reasonable expectations of the person whose data you took from a public profile.

The parts that fail in practice are usually the same. Volume without relevance, where a whole board is scraped rather than a role sourced. Retention long after any plausible interest has expired. Silence, where the person is never told you hold their data. And a lack of any record showing the assessment happened at all.

The product carries the assessment reference on the record, keeps the source and the date of collection, runs the retention clock from real contact and surfaces expiry for a decision. What it cannot do is perform the balancing test. That is a controller judgement, and it needs writing down before the sourcing starts rather than after a complaint arrives.

A candidate whose data you obtained from somewhere other than the candidate has to be told: who you are, what you hold, where you got it, why you are processing it, on what basis, for how long, and what rights they have. There is a deadline for telling them, and the first contact you make is usually the moment it has to happen.

In practice most sourced candidates are never told, because the notice lives on a website nobody visits and the outreach message says nothing about it. The product supports doing this properly: privacy notice text can be attached to outreach templates so the first message carries it, the notice version shown is recorded against the record, and the candidate portal gives a route to see what is held without emailing anybody.

None of that decides your wording. The notice is yours, it names your firm as controller, and it has to describe your actual practice rather than a generic paragraph. A notice that does not match what you do is worse than a short one that does.

Retention measured from record creation is the wrong clock. A candidate placed eighteen months ago and spoken to last week is a live relationship; a record parsed three years ago that has never replied is not, whatever the creation date says. Windows in the product run from the last meaningful contact: a reply, an answered call, an application, a submittal, an interview or a portal update the candidate made themselves.

Meaningful is defined narrowly. A bulk campaign the candidate ignored does not reset the clock, and neither do opens or delivery receipts. If they did, retention would become a function of how often you email people rather than of whether a relationship exists.

At expiry the record surfaces in a review queue carrying its basis, its last contact and three options: extend with a recorded justification, contact the candidate to refresh, or erase. Automatic deletion on a timer sounds tidy and destroys records somebody had a live reason to keep, while leaving no evidence that any decision was taken.

Access is a self-service export from the record: the structured profile, parsed resume text, custom fields, notes, message history, call and interview records, stage and disposition history and consent events, as CSV for a person and JSON for a system. It runs without a support ticket in the path, because a statutory deadline should not depend on a vendor's queue.

Rectification is editing the record with an audit trail, and candidates can correct their own details through the portal, which is usually more accurate than a recruiter's two-year-old guess. Erasure removes the profile, custom fields, notes, messages, the original uploaded file, the extracted text and the search representation together, and keeps a fulfilment record which is the fact of the request rather than the data it concerned.

Restriction flags a record so it is excluded from search, matching and outreach without being deleted. Objection to processing, including objection to direct marketing, sets suppression that survives re-import, which matters because the most common failure is a suppressed person reappearing through a fresh spreadsheet. Portability uses the same structured export as access.

Match scores are decision support, not decisions. A score is shown with the requirement that drove each point, a person reviews it, and the product does not auto-reject candidates on a score threshold. Keeping a person in the loop is a design position and it also happens to keep the processing outside the narrowest reading of automated decision-making with legal or similarly significant effect.

Explainability is the practical control. A score nobody can inspect cannot be defended, and a scoring system that cannot be explained launders a judgement into something that looks like a measurement. Field-level explanations let a recruiter disagree with the model, which is the entire point of having one.

Where a jurisdiction adds its own rules on automated tools, such as New York City's bias audit regime, the product records which candidates were scored and exports the data an independent audit needs. Commissioning that audit and issuing notice remain yours.

Primary processing is in the United States on AWS us-east-1, which makes this an international transfer for UK and EU customers. The mechanisms are the European Commission standard contractual clauses and the UK international data transfer addendum as applicable, incorporated through the data processing addendum, with a transfer impact assessment and the supplementary technical measures described in the security overview.

Those are the mechanisms available to a US processor today. What they are not is a guarantee about how a regulator or a court will view a given transfer in the future, and any vendor offering that certainty is selling something it does not have. The assessment is a document to read with counsel, not to file unread.

Subprocessors add their own transfer questions, particularly model providers and messaging providers. The register states where each category processes, which is the field to read if you carry a residency requirement, and objections during the notice period are the mechanism for acting on what you find there.