Maya runs talent acquisition operations at Brightline Health, a 900-person company spanning clinical, engineering, and administrative roles. When the legal team flagged the company for a privacy review, Maya pulled up the standard online application form and counted the fields candidates were asked to complete: 38 of them. Date of birth. Graduation year. A headshot. Marital status. Salary history. Most had been added years ago by people who no longer worked there, for reasons no one could explain, and none of them appeared in a single hiring decision Maya could recall. What she had was not a thorough process. It was a liability surface, and a growing one now that the company was feeding application data into an AI screening tool. Data minimization is the discipline that turned Maya's 38-field form into a 14-field form she could defend to an auditor, to a regulator, and to herself.

What Data Minimization Actually Means

Data minimization is the principle that you should collect, store, and process only the personal data you genuinely need for a defined purpose, and no more. In recruiting, that purpose is making a sound, lawful hiring decision for a specific role. If a data point does not contribute to that decision, the default is not to collect it. The principle sounds obvious until you try to apply it, at which point you discover how much of your process runs on "we might use this sometime," "better to have it than not," and "other companies collect this." None of those are reasons. They are habits wearing the costume of prudence.

This is not a soft best practice. It is written into law. The EU General Data Protection Regulation states in Article 5(1)(c) that personal data shall be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." The same article, at 5(1)(e), adds storage limitation: data must be kept "for no longer than is necessary" for those purposes. California's Privacy Rights Act amended the CCPA to add a parallel duty, codified at Civil Code section 1798.100(c), that a business's collection, use, retention, and sharing of personal information be "reasonably necessary and proportionate" to the purpose for which it was collected. Different jurisdictions, same core rule: necessity, not convenience, governs what you are allowed to hold.

Over-collection also creates ordinary operational burden that has nothing to do with regulators. Every data point carries a privacy obligation. You have to track it, secure it, disclose it, and eventually delete it. Candidates wonder what you are doing with it. And after all that, you are still making the decision on a small fraction of what you collected. For an AI-assisted recruiter, minimization carries an extra weight on top: every field you collect is a field that can end up in a model's context window. The smaller and cleaner the input, the smaller the surface for both privacy harm and biased inference. You cannot leak, mishandle, or discriminate on data you never collected.

The Data Inventory: Start by Listing What You Take

Before you can cut anything, you have to see the whole picture, and most teams have never written it down in one place. Maya's inventory ran to eleven categories: resume, cover letter, work samples or portfolio, background check, references, assessment results, interview notes, social media information, candidate communication such as emails and chat messages, salary history or expectations, and demographic information. Some were required, some optional but requested, some gathered only sometimes, and several were being collected by systems rather than by people, which is why nobody had noticed them.

Then comes the question that does the work: do I actually need this to make a hiring decision? Not "could this conceivably be relevant," but need. Running the eleven categories through that question produces a set of answers that are uncomfortable in a useful way.

Candidate communication, the eleventh category, is the one nobody inventories because it accumulates automatically. Emails and chat messages sit in systems by default, they contain personal detail nobody screened for, and they outlive the requisition unless something deletes them. It belongs on the inventory precisely because no one chose to collect it.

The Field Audit: 38 Fields Down to 14

Maya's first move was to print the form and put every field through one question borrowed straight from GDPR: is this adequate, relevant, and limited to what is necessary to decide whether to hire this person? She graded each field keep, cut, or conditional. Here is how the 38 fields resolved.

Kept (14 fields). Full name; email; phone; work authorization status (a yes/no, not a country of origin); resume or work history; the specific role applied for; how the candidate heard about the opening; relevant licenses or certifications for clinical roles; a free-text "anything else we should know" box; consent acknowledgment; preferred pronouns (optional, used only for correct address, never for screening); a portfolio or work-sample link for roles that evaluate output; availability or start date; and salary expectations for the role, which is a forward-looking number rather than a history.

Cut (the expensive ones). Date of birth was removed outright. It is a direct identifier of age, a protected characteristic under the federal Age Discrimination in Employment Act, and it served no purpose before an offer, when a background check would confirm identity anyway. Graduation year went next, and this one is subtle: it is a near-perfect proxy for age. A 1996 graduation date tells a screener, human or machine, roughly how old someone is. The U.S. Equal Employment Opportunity Commission's guidance on disparate impact is the relevant frame: a facially neutral practice that disproportionately disadvantages a protected group can be unlawful unless it is job-related and consistent with business necessity. Asking for graduation year is asking for an age proxy, and an age proxy fed to an AI screen is disparate-impact exposure with no offsetting business need. The headshot was cut because a photo broadcasts race, approximate age, gender presentation, and sometimes religion or disability, none of which may lawfully influence a hiring decision and all of which a vision-capable model can read. Marital status, number of children, and gender were removed as classic special-category or protected-class data with zero bearing on competence. Salary history was eliminated; beyond anchoring offers to a candidate's prior underpayment, it is banned outright for hiring use in a growing list of states and cities, so collecting it created risk with no upside.

Conditional. A few fields survived only for the roles that truly needed them. Driving record applies to roles that involve driving, not to a software engineer. Background-check authorization is gathered late, at the offer stage, not up front from every applicant. Demographic data for EEO reporting, where legally required, is collected on a separate, voluntary form that is firewalled from the hiring file and never reaches the screening tool, which is exactly how the EEOC contemplates such data being handled.

The arithmetic is blunt: 38 fields became 14. Candidate completion time dropped, drop-off fell, and the legal team's exposure shrank to fields each tied to a documented purpose.

The Elimination Decision Framework

Maya's audit worked because it applied the same five tests to every field rather than arguing case by case about which ones felt important. The framework is worth stating explicitly, because it is portable to any recruiting process.

• Necessity. Is this data necessary for the hiring decision? Not nice to have. Necessary.
• Predictiveness. Does this data predict job performance? Not "might be relevant." Actually predict.
• Risk. What is the privacy and compliance risk of collecting it? Salary history can expose pay inequity concerns; social media can expose bias risk.
• Burden. What does providing it cost the candidate? Cover letters take writing time, assessments take hours, references require them to spend other people's goodwill.
• Decision. Given necessity, predictiveness, risk, and burden together, should you collect it?

Applied to salary history, the framework resolves quickly. Is it necessary? No, because you can set compensation from the role. Does it predict performance? No. What is the risk? High, because it can expose your own salary inequity and may be illegal where you operate. What is the candidate burden? Moderate, since they have to look it up. Verdict: do not collect. Applied to a portfolio for a design role, the answers reverse. Necessary? Yes. Predictive? Yes. Risk? Low. Burden? Moderate, because they have to assemble it. Verdict: collect. The value of running both is that the framework produces a defensible written reason either way, which is what separates minimization from an opinion about forms.

Reducing Assessment Load

Assessments deserve their own pass, because they have quietly become ubiquitous and they are the heaviest thing you ask a candidate to carry. Coding assessments, personality assessments, skills assessments, culture-fit assessments: many organizations administer several without ever asking whether the combination adds value. The result is a candidate spending 3 hours on assessments for a role that might take 30 minutes to interview for, and a hiring team that reads one of the reports.

The better approach is to ask which single assessment, if any, is genuinely predictive of performance in this role, use that one, and eliminate the rest. The answer varies sensibly by role. For technical roles, a coding assessment measures actual ability and earns its place. For non-technical roles it measures nothing you need. For roles that turn on communication, a conversation with a skilled interviewer is often more predictive than any instrument you could buy. Cutting the battery down is not lowering your standards; it is refusing to spend a candidate's time on data you will not use.

The Data Map: What Ever Reaches the AI

Cutting the form was only half the job. The other half was answering a question most recruiting teams cannot: of the data we do collect, which fields ever reach the AI screen? Maya built a one-page data map with three columns, field, purpose, and "reaches AI? yes/no."

The mapping forced hard distinctions. The resume and the role applied for reach the AI, because matching experience to requirements is the model's job. Work-authorization status does not reach the AI; it is a downstream eligibility gate handled by a human, and feeding it to a model risks the model treating it as a screening signal. Contact details never reach the AI; there is no reason a screening model needs an email address, and excluding it removes a direct identifier from the context window. The optional pronouns field, the EEO demographic form, and the consent record all sit firmly in the "no" column, walled off from the model entirely.

This map is what turns minimization from an intention into an enforceable control. It tells the engineer wiring up the screening tool exactly which fields to pass and which to withhold, and it gives Maya a document she can hand an auditor that shows protected-class data and bare identifiers never entered the model's reasoning.

Why Minimization Cuts Legal Risk and Bias Risk at Once

Most controls trade one risk for another. Data minimization is unusual in that it reduces two distinct risks with a single action, which is why it is worth the effort of the audit.

The legal risk is the obvious one. Under GDPR, holding data you cannot justify as necessary is a standalone violation of Article 5(1)(c), independent of any breach. Under CPRA, the same is true of California's proportionality requirement. Every field you do not collect is a field you cannot be fined for over-collecting, cannot expose in a breach, and need not account for in a data-subject access request. Fewer fields means a smaller compliance footprint across every privacy law that applies to you.

The bias risk is the one teams overlook. Protected characteristics and their proxies are dangerous precisely because models are good at finding patterns in them. Feed an AI screen a graduation year and it can learn, without anyone intending it, that older candidates score lower. Feed it a headshot and it can pick up race or gender. The EEOC's disparate-impact doctrine does not require intent to discriminate; it asks whether a practice produces a disproportionate adverse effect on a protected group without business necessity. The cleanest defense against building such a practice into an AI tool is to never put the proxy in front of the model. Minimization is bias prevention by construction: you cannot discriminate on a signal that is not in the input.

Retention and Deletion: Minimization Over Time

Collecting less is the first half of minimization. Keeping it for less time is the second, and it is the half most teams ignore. GDPR's storage-limitation principle in Article 5(1)(e) is explicit that data may not be kept longer than necessary, and CPRA's proportionality duty extends to retention as well. "We have always kept everything forever" is not a retention policy; it is the absence of one.

Maya wrote a schedule with a defined clock for each category rather than one blanket rule. Resumes and basic application data for candidates not hired are retained for the period needed to defend against a discrimination claim, then deleted; in the United States, EEOC recordkeeping rules require employers to keep application records for a minimum window after the hiring decision, so the schedule sets a firm retention period that satisfies that obligation, commonly in the range of 6 to 12 months for basic application data, and then triggers deletion rather than indefinite storage. Hired-candidate application data folds into the employee record under its own retention rules. Interview notes run longer, because they can be evidence in a discrimination claim, and are kept for a defined multi-year window, at least 1 to 2 years, before being purged. Assessment data for rejected candidates has no reason to survive the decision it informed and is deleted once the hire is made. Reference notes are deleted after the hire, since they are not legally required once the decision is final. Background-check results follow the legally mandated period for their jurisdiction, which varies, so the schedule points at the jurisdiction rather than guessing. Social media notes, if any were taken, are deleted immediately after the hiring decision, because there is no defensible reason to keep them. Anything else with no legal hold and no active use, including screening-tool intermediate outputs, is deleted at the close of the requisition.

Two disciplines make that schedule real. The first is that every category has an owner, a clock, and an automatic deletion trigger, so data does not accumulate by default. The second is consistency: if your rule is that rejected-candidate data goes at the close of the requisition, it has to go for everyone, because a retention policy applied selectively is worse evidence than no policy at all.

Building Minimization Into the Process

An audit you run once decays. Maya made minimization a standing control with a handful of habits. Every new field proposed for the application form must arrive with a written purpose and a named owner before it can be added, and "might be useful someday" is an automatic rejection. The form and the data map are reviewed on a fixed quarterly cadence, because fields creep back in and AI tooling changes what reaches the model. The team audits its vendors, the applicant tracking system and the screening tool, because those systems often collect and retain more than the recruiter realizes, and a vendor's default settings are not a minimization policy.

Two further habits matter as much and are easier to skip. The first is leadership buy-in: some leaders assume that less data means worse decisions, and the way through that is evidence rather than principle, showing that good decisions come from relevant data rather than volume. The second is telling candidates, in a short privacy notice, what is collected and why. That satisfies transparency obligations and acts as a forcing function, because a field you would be embarrassed to explain to a candidate is usually a field you should not be collecting. Training closes the loop: the recruiters and coordinators who actually touch the form need to know what is collected and why, or the policy lives only in Maya's head.

None of this made Maya's hiring slower or less rigorous. It made it more defensible. When the next privacy review came, she did not scramble. She handed over a 14-field form, a data map, and a retention schedule, and the review was over in a morning.

Anti-Patterns

The comprehensive backup strategy. The team collects data just in case it is needed later, with no articulated use case. It happens because it feels prudent; you cannot know in advance what will turn out to matter, and gathering it is cheap at the moment of collection. What goes wrong is that the cost arrives later and lands somewhere else: privacy and storage burden, a larger breach surface, and candidates who wonder what you are doing with information you never explained. The fix is to require a specific use case before a field is added. If you cannot name what decision the data will inform, do not collect it.

The assessment pile-on. The team administers a coding assessment plus a personality assessment plus a communication assessment where one, or none, would do. It happens because each instrument seems valuable in isolation and comprehensive evaluation feels like rigor. What goes wrong is candidate fatigue, drop-off among exactly the strong candidates who have other options, and a decision that was never actually improved because nobody read all the outputs. The fix is to test each assessment against a single question, does this predict performance in this role, and keep only the ones that survive it.

Proxy collection. The team collects a stand-in for what it actually wants to assess: salary history as a proxy for value, social media as a proxy for culture fit. It happens because the proxy is easier to measure than the real thing, and measurable feels like objective. What goes wrong is that proxies carry bias and legal risk while frequently failing to predict anything, and a proxy handed to an AI screen becomes a discriminatory signal the model will happily learn. The fix is to assess the thing directly. If you want to evaluate communication, use an interview. If you want to evaluate culture fit, define what you actually mean by it and assess that.

Practice

• Run a data inventory. List everything you currently collect from candidates. For each item, write one sentence explaining why. If you cannot write the sentence, you have found a candidate for elimination.
• Audit predictiveness. Pick three categories you collect and write down what job performance outcome each predicts. If you cannot answer confidently, the data probably is not necessary.
• Evaluate every assessment. For each pre-screening assessment in your process, ask whether it predicts job performance and whether anyone uses the result, or whether the team is going through the motions.
• Calculate candidate burden. Add up how long your process takes a candidate end to end: resume, cover letter, assessments, interviews. If a non-executive role costs them more than 4 hours, look hard at what can go.
• Review retention. For each category you keep, write down how long you keep it, why, and what the legal requirement actually is. Eliminate any retention period longer than that requirement supports.

Reflection

• What is one data category you collect that you have never actually used to make a hiring decision?
• If you had to defend your current collection practices to a privacy auditor tomorrow, where would you feel most exposed?
• How long is your average candidate spending on assessments and data entry during your process?
• What is preventing you from eliminating the categories that are not predictive?
• If you cut your current data collection in half, would your hiring decisions actually get worse, and what evidence do you have either way?

Glossary

• Data inventory. A catalog of every data category you collect from candidates.
• Necessity test. Asking whether data is genuinely required for the hiring decision rather than merely nice to have.
• Predictiveness. Whether a data point actually predicts job performance.
• Proxy data. Data collected as a stand-in for what you really want to assess. Frequently introduces bias.
• Disparate impact. A facially neutral requirement that systematically disadvantages a protected group.
• Retention period. How long a category of data is kept before deletion.
• Assessment battery. Multiple assessments administered to the same candidate, which should be evaluated for cumulative rather than individual value.
• Data map. A field-by-field record of which collected data reaches an AI tool and which does not.

Related Lessons

• Data Privacy Fundamentals: GDPR, CCPA, FCRA, and Regional Requirements sets out the wider regulatory landscape the minimization duties in this lesson sit inside.
• Consent and Transparency: What Candidates Need to Know covers the notice that makes your collection decisions visible to candidates, and is the forcing function for the field audit.
• Privacy Boundaries: Data Sharing, Tool Selection, and Compliance extends minimization to what you hand a vendor once the data is already in your systems.
• Retention and Deletion: Reasonable Timelines and Clean Data Practices turns the retention schedule sketched here into a full operational policy.
• Hands-On Project: Audit a Recruiting Process for Privacy Risks is where you run this audit against your own funnel end to end.

Closing

Data minimization is not only a privacy control; it is a decision-quality control. When you collect only what you need, you are forced to state what you actually value in a candidate, which is a harder and more useful exercise than adding another field. You reduce noise, you focus on signal, and you respect the time of the people applying to you, who notice. Maya's form is the visible artifact, but the real output of her audit was a written answer to a question her team had never had to answer before: what, exactly, are we deciding on? Minimize ruthlessly and you will get that answer too.

Key Takeaways

• Necessity is the legal standard, not a preference. GDPR Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary," and CPRA's amendment to the CCPA (Civil Code 1798.100(c)) requires collection to be "reasonably necessary and proportionate." Over-collection is a standalone violation, not just a breach waiting to happen.
• Inventory before you cut. List every category you collect, including the ones systems collect automatically such as candidate emails and chat messages, then ask of each whether you need it to make a hiring decision. Several standard categories, references as typically used, salary history, and social media research, do not survive that question.
• Audit field by field with one question. For each item on your form, ask whether it is adequate, relevant, and limited to what is necessary for this decision. Maya's audit cut a 38-field form to 14 by removing date of birth, graduation year, photo, marital status, and salary history, each with a documented reason.
• Score every field on five tests. Necessity, predictiveness, risk, candidate burden, and then the decision. Running salary history and a design portfolio through the same framework produces opposite verdicts and a written reason for each, which is what makes the outcome defensible.
• Proxies for protected traits are the silent risk. Graduation year encodes age; a headshot encodes race, age, and gender. The EEOC's disparate-impact doctrine reaches facially neutral practices without business necessity, and a model will exploit any proxy you hand it. The defense is to never put the proxy in the input.
• Assessment load should be proportionate. A short coding assessment for a technical role earns its place; a multi-hour battery for any role does not. Keep the one instrument that predicts performance and cut the rest.
• Map what reaches the AI. Collecting a field is not the same as feeding it to a model. A field-by-field data map showing which inputs reach the screening tool keeps identifiers and protected-class data out of the model's context and gives you a document an auditor can verify.
• Minimization cuts legal and bias risk together. One action shrinks your compliance footprint under every privacy law and removes the signals an AI screen could discriminate on. Few controls reduce two distinct risks at once.
• Retention is minimization over time. GDPR Article 5(1)(e) storage limitation and CPRA proportionality both require deleting data when its purpose ends. Give every category an owner, a defined clock that satisfies EEOC recordkeeping minimums, and an automatic deletion trigger, and apply the schedule consistently.
• Make it a standing control. New fields require a written purpose and owner, the form and data map get a quarterly review, vendors get audited, the team gets trained, and candidates get a plain-language notice of what you collect and why.

Frequently Asked Questions

Will collecting less data make our hiring decisions worse? This is the objection Maya heard from leadership, and the answer is that decision quality comes from relevant data rather than volume. The fields she cut, date of birth, graduation year, headshot, marital status, salary history, had never appeared in a hiring decision she could recall; they were adding noise and legal exposure without adding signal. If you suspect a category genuinely carries signal, the framework gives you a way to test the claim: state what job performance outcome it predicts. If nobody can answer that, the field was not helping.

How is salary expectations different from salary history? Salary history asks what a previous employer paid the candidate, which anchors your offer to someone else's decision, potentially replicates their underpayment, and is banned for hiring use in a growing list of states and cities. Salary expectations ask what the candidate is looking for in this role, which is forward-looking, relevant to whether you can reach agreement, and carries none of the same baggage. Maya kept expectations and cut history for exactly that reason.

We are legally required to collect EEO demographic data. Does that conflict with minimization? No, provided you handle it as a separate stream. The requirement is to collect it for reporting, not to place it in the hiring file or the screening tool. Maya's approach was a separate, voluntary form, firewalled from the hiring record and never passed to the AI, which is how the EEOC contemplates such data being handled. Minimization is about purpose limitation as much as volume: data collected for reporting stays in reporting.

How do we decide a retention period when the law is vague? Anchor it to a purpose rather than a feeling. For application data the purpose is defending a potential discrimination claim, which is why EEOC recordkeeping minimums set the floor and interview notes, which are the strongest evidence in such a claim, get the longest window. Where the requirement varies by jurisdiction, as with background-check results, point the schedule at the jurisdiction instead of guessing a number. The unacceptable answer is indefinite retention, because that is not a period at all.