Candidate data is a liability until governed.

The files an organization keeps on its employees are anchored to a living relationship: a contract, a payroll record, a career still in motion. The files it keeps on rejected candidates are anchored to nothing but a decision that has already been made. Yet in most hiring operations the second collection is larger than the first, more sensitive than most of what HR holds, and growing faster. Every assessment campaign deposits scores, response records, behavioral traces, and video from hundreds of people, most of whom will never work there, into an archive that no one owns, no schedule governs, and no process empties.

Candidate data privacy is the discipline of treating that second archive as what modern privacy law says it is: a store of personal data whose justification expired with the decision it served. The governing principles are consistent across regimes. Collect only what the decision needs, tell people what you collect, use it only for that purpose, keep it only as long as you can justify, and delete it when the justification ends. Nothing in that list is subtle. What is subtle, and what most assessment programs get wrong, is whose job the list is.

In the standard arrangement the employer is the controller, the party that decides why and how candidate data is processed, and the assessment platform is a processor acting on the employer's documented instructions. That split assigns the homework, and it does not transfer with the invoice. The regulatory map, which statutes apply where and what each demands of automated hiring, belongs to the companion article on AI hiring regulations; the governance of the security program around assessment belongs to the study of assessment security. This article follows the data itself: what the funnel collects, on what basis, held how long, and ended how.

What the funnel collects about the people it declines

Start with an inventory, because most programs have never taken one. The gentlest category is identity and contact data: names, email addresses, phone numbers, the résumé itself. It reads as administrative, but it is personal data in every regime, and it is the join key that connects every other record in the archive to a findable human being. An anonymized score is a statistic; the same score next to a name and an email address is a dossier entry.

Above it sit scores and response-level records. A report holds judgments about a person: how they reasoned, where their personality profile sits, what a hiring team concluded. Beneath the report, most platforms also retain the item-by-item response record that produced it, a layer many buyers do not know they hold. Evaluative content is more sensitive than contact data for a simple reason: leaked contact details inconvenience a person, while leaked judgments about intelligence or temperament can follow one.

Then come the behavioral traces: response timings, navigation patterns, device and session signals, the raw material of integrity monitoring. Individually banal, they aggregate into a record of conduct, and conduct records invite inference. Beyond them sits proctoring media, where the funnel stops resembling a filing cabinet: screen recordings, camera video of a face and the room behind it, sometimes audio of a home. And at the far end, identity documents, collected where verification demands them, which raise questions of their own that a later section takes up. Figure 1 orders the five categories by intrusiveness, and the ordering is the beginning of policy: the further right a category sits, the shorter it should live and the fewer people should ever see it.

Candidate data privacy runs on six plain sentences

The EU's General Data Protection Regulation (Regulation (EU) 2016/679) is the reference architecture here, not because every reader operates in Europe but because most modern regimes are drafted in its shadow, and its principles compress to sentences a hiring leader can hold in memory. The first: processing needs a lawful basis, a legal justification named before collection starts, and the person must be told, plainly, what is collected and why. In assessment, that means the candidate notice is a design artifact rather than a legal afterthought pasted above a checkbox: what a person is told about collection, before the sitting begins, is part of how she experiences the entire process, a connection the companion article on candidate experience takes up in full.

Which basis fits is not a free choice. The Article 29 Working Party, the coordinating body of the EU's data-protection authorities and predecessor of the European Data Protection Board, advised in its opinion on data processing at work that employment-context processing, recruitment explicitly included, must be proportionate to what the employer is deciding, and that consent is rarely a sound lawful basis in this setting: the power imbalance between the parties means a candidate facing a job she wants cannot meaningfully refuse (Article 29 Data Protection Working Party, 2017). A funnel that treats a checked consent box as settling the matter has built on a foundation the regulators themselves distrust.

The second and third travel together. Purpose limitation says data collected for a hiring decision is used for that decision, not for whatever purpose later seems attractive. Data minimization says collect only what the decision needs, a principle assessment is unusually well placed to satisfy, since an instrument built around what measurably predicts performance collects less by construction than a process that hoards signals in case they help.

The fourth is storage limitation: keep personal data no longer than the purpose justifies, which for a concluded hiring decision is a duration with an end. The fifth is the right to erasure (Article 17), the person's power to demand deletion when no ground for keeping the data remains. The sixth is integrity and confidentiality, the duty to secure what you hold while you hold it; a program that fails here fails all the others at once, since every principle assumes the data stays where it was put. One further provision deserves a clause: where a decision about a person is made solely by automated means, additional safeguards attach (Article 22), terrain the regulatory-map article covers in full.

India's Digital Personal Data Protection Act, 2023, with implementing rules issued in 2025, arrives at the same shape from a different legal tradition: consent and notice obligations, purpose limitation, erasure and correction rights, duties on data fiduciaries (the Act's term for the party deciding the processing), and the principle that data should not be retained beyond the purpose for which it was collected. For a hiring funnel touching Indian candidates, the practical instructions converge with the European ones to a degree that should be reassuring: one lifecycle, run properly, satisfies the spirit of both. Where regimes differ, in thresholds, timelines, and the treatment of special categories, the jurisdiction-specific calls belong with counsel; the sentences above are the part that does not move.

The controller does the homework, and the controller is you

Privacy law divides the labor of those sentences between two roles. The controller decides the purposes and means of processing: why the data exists, what is collected, how long it is kept. The processor handles the data on the controller's documented instructions, and owes it competent, secure processing. GDPR-style regimes expect the split to be written into a data processing agreement, the contract clause that turns an implied arrangement into an auditable one, and the Indian regime places the equivalent weight on the data fiduciary.

Map those roles onto an assessment funnel and the standard allocation is rarely in doubt. The employer chose to assess, chose whom to assess, defined what the results are for, and decides how long the records live: controller. The platform scores, stores, and secures those records on instruction: processor. GDPR recruitment data obligations therefore sit with the employer even when every byte lives on the vendor's servers, and the same logic runs through the Indian statute. Vendor quality is genuinely important, but it is important within the processor's column; no amount of it reaches across the table.

This is the operational insight most programs miss, and the failure mode has a recognizable sentence: the platform handles privacy. A regulator hears that sentence as a category error. The platform can encrypt, isolate, and delete on command with perfect competence, and the employer still owns the questions competence cannot answer: on what lawful basis was this candidate assessed, why is her video still held months after rejection, and who responds, on a statutory clock, when she asks for her file or its deletion. Buying a better processor improves the processing. It cannot supply the decisions that make the processing lawful.

Figure 2 sets out the standard allocation. Readers of the assessment security article will recognize the format, and the resemblance is deliberate but the content is disjoint: that grid allocates incident operations, who acts when something goes wrong, while this one allocates data obligations, who owes what about the records themselves. The rows that never leave the employer's column are the first three. The bottom row is the working partnership in miniature: the employer instructs deletion, and the platform executes it and proves it.

"As long as necessary" is a question, not an answer

Storage limitation is the principle assessment programs violate most, because violating it requires no action at all. Every statute phrases the duty the same way: keep personal data as long as necessary for the purpose, and no longer. That phrasing is an assignment, not a safe harbor. It obliges the controller to answer two questions per category of data: necessary for what, and until when. Legitimate answers exist. A dispute window after a decision is a purpose; an audit trail for a regulated process is a purpose; and compliance monitoring can legitimately outlive individual decisions when the data is aggregated or pseudonymized, stripped of direct identifiers, the case made in the companion articles on adverse impact monitoring and AI hiring regulations. Each of those purposes carries its own clock, and when the clock runs out, so does the justification.

Regulators have been specific about this in the recruitment context. The UK Information Commissioner's Office addresses selection records directly in its employment practices code: collect only what the decision requires, tell candidates what is held about them, and set retention periods for unsuccessful applicants' records rather than defaulting to indefinite storage (Information Commissioner's Office, n.d.). The code reads less like statute than like the schedule this section is asking for, written by the authority that would otherwise ask why it does not exist.

The default that actually operates in most funnels answers neither question: keep everything, forever, because deletion was never anyone's task. The archive grows silently, a few thousand records per campaign, each individually forgettable and collectively a liability with compound interest. What ends the silence is rarely an internal review. It is a subject-access request, the right of any person to demand a copy of what you hold about them, which converts the whole pile into something that must be located, read, and defended on a statutory deadline; or it is a breach, which converts the pile into exposure. The second scenario carries a widely quoted price: IBM Security's Cost of a Data Breach Report, an industry estimate from a vendor study, put the global average at $4.88 million in its 2024 edition (IBM Security, 2024). The exact figure matters less than the asymmetry it illustrates: records held past their purpose contribute their full weight to a breach and nothing at all to hiring.

Figure 3 draws the lifecycle the schedule should govern. Minimization operates at the left edge, before anything is collected; storage limitation operates after the decision, where a defined retain window, sized to disputes and audit, hands off to erasure on schedule or on request, and erasure hands off to proof. The clock in the figure has no numbers on it, and that is the figure's argument. No statute publishes the durations, no vendor default supplies them, and no two categories in Figure 1 deserve the same one. The durations are the controller's to set, which is another way of saying they are yours.

Erasure that means something

Deletion arrives in a well-run funnel by two routes, and both need to work. The first is the schedule itself, running without anyone asking: when a category's clock expires, the records go, as routinely as an invoice is paid. The second is the request. The right to erasure in hiring contexts means a rejected candidate can ask that her file be deleted, and the controller must act on a statutory timeline unless a defined ground for keeping the data remains, a dispute in progress being the obvious one. India's regime pairs the same right with correction, and adds its own weight to the point that retention beyond purpose needs a reason.

The operational bar is provable deletion, and it is higher than pressing a button. Candidate data does not live in one table. It lives in the primary store, in rendered reports, in exports someone downloaded, in the media and evidence repositories behind integrity review, and in backups. A deletion that reaches the dashboard and misses the annexes is a deletion in the interface only. The workable standard, and the one worth writing into the data processing agreement, is a deletion record: what was deleted, from which systems, on what date, and when the last backup copy expires. Backups are the honest complication; the accepted practice is immediate removal from live systems with backup copies aging out on the documented rotation cycle, stated plainly rather than hidden.

Erasure has boundaries, and stating them keeps the policy credible. Evidence captured during an integrity review can be retained through a live dispute; the companion article on integrity flags sets out the model, captured records held under a defined policy rather than an open-ended one. The load-bearing word is defined. A policy that names its purpose and its end date is storage limitation working as intended; a folder of session video kept in case it is ever useful is the unset default from Figure 3 wearing a compliance costume.

Proctoring media is the hardest case, so it gets the strictest handling

Every principle in this article tightens when the data is a recording of a person's face, voice, screen, and home. Proctoring media is the category where an assessment funnel is most obviously inside someone's private space, invited but not casually: the camera sees the room behind the candidate, the microphone hears the household, and the screen capture sees whatever else was open. The case for capturing any of it at all is proportionality, argued in the companion article on proctoring: observation scaled to the stakes of the decision, announced in advance, never maximal by default. Data handling inherits that logic and extends it past the sitting.

Identity verification adds a legal edge worth naming carefully. Under the GDPR, special-category data, the tier receiving heightened protection, includes biometric data processed for the purpose of uniquely identifying a person. Identity-verification imagery may therefore constitute biometric data, depending on how it is processed: the same photograph sits differently in law when a human glances at it than when a system computes a match against it. A program does not need to resolve that question in the abstract; it needs to know, concretely and in writing, which kind of processing its own verification step performs.

The handling rule that follows is the strictest version of everything above, drawn in Figure 4. Capture the minimum the stakes justify. Retain media on the shortest clock of any category, sized to the review and dispute window and nothing more. And narrow access hardest: named reviewers, a logged reason per viewing, no standing access for anyone whose job does not include watching. A recording that thousands may view is a different object, in risk and in law, from one that three people may view for a reason that is written down.

Owning the archive: what to do this quarter

Candidate data privacy improves through a short list of unremarkable moves, all of them controller-side, and all of them available without waiting on a vendor roadmap. The pattern across this article is that every failure traced back to an absence rather than an act; the remedies are the corresponding presences.

• Appoint an owner for the candidate archive. One named person who can answer, at any moment, four questions: what is held, where it lives, on what basis, and until when. Those four answers are the whole job description, and every risk this article has described begins where they are missing.
• Set the retention schedule now, category by category. Assessment data retention is not one clock but several: Figure 1's categories each deserve their own, with proctoring media on the shortest. The schedule is the controller's document. Vendor defaults, however sensible, are a starting suggestion from a party that does not own the obligation.
• Put the split in the contract. A data processing agreement that names controller and processor, routes rights requests with deadlines attached, and specifies deletion on instruction with proof. A vendor that publishes its security and data-protection practices has made this diligence cheaper; the agreement is what makes it binding.
• Ask the erasure question with a deadline attached. Deleted from where, including backups on what rotation, proven how, within how many days of instruction. A vendor with a real answer names systems and windows. A vendor who answers with the word "compliant" has answered a different question.

Hiring at scale will keep producing records about strangers; that is what evaluating people entails, and no part of this article argues against evaluating them well. What the process need not produce is a permanent, unowned copy of everything it ever touched. A candidate archive with an owner, a schedule, and a deletion path is the entire proposal, and it is one the plain sentences of every regime discussed here already contain. Candidate data privacy, done this way, stops being a legal anxiety and becomes what retention, minimization, and erasure have always actually been: ordinary operational hygiene, applied to people who trusted you with an afternoon of their lives.