Most candidates never find out why they were filtered out. They upload a resume, answer a few questions, and hear nothing — or they sit through a recorded interview and get a form rejection three weeks later. That silence is where complaints begin, and eventually claims. If your organisation uses software to rank resumes, score recorded answers, or schedule interviews, the checklist below is meant to be worked through line by line. It covers what to document, what to tell people, how to test for unfair outcomes, and what a candidate can reasonably ask you for.
Start With an Inventory, Not a Policy
A policy nobody can map to a real system is decoration. Before writing anything, list every tool in the hiring funnel — including the ones sitting quietly inside your applicant tracking system that nobody explicitly bought.
- Tool name and vendor, plus how you'll be notified of version or logic changes
- The stage it touches: sourcing, screening, ranking, scheduling, interview scoring, background checks
- The decision it informs, and whether a human can override it
- Inputs it uses — and inputs it must ignore
- Where candidate data is stored, for how long, and who can access it
- The person internally accountable for how it performs
If two people on your team give different answers about the same tool, that's the first gap to close.
Transparency: Say What the Candidate Is Dealing With
You don't need to publish source code. You do need to tell candidates, before they invest an hour of their evening, that automated tools are part of the process, what they're used for, and how to ask questions about them. A single sentence in a forty-page privacy policy is technically present and practically useless.
What your notice should cover
- That automated tools are used, and at which stages
- What is collected — including recordings, voice, or behavioural signals where those apply
- Who reviews the output and how long it is kept
- How to request human review
- How to request an accommodation or an alternative format
- A named contact, not a generic inbox
The interview stage deserves its own explanation
Recorded or analysed interviews are the part candidates worry about most. People should know before they begin whether a person will watch the recording, whether the system produces a score, whether they can choose a live conversation instead, and how to withdraw without losing their application. If you can't answer each of those in one clear sentence, the process isn't ready to launch.
Bias: Test Before Launch and Keep Testing
Fairness isn't a certificate you collect once. Screening systems learn from historical data, job descriptions, and design choices — all of which carry the assumptions of whoever built them.
What to look at
- Pass-through rates at each stage, by group, where you lawfully hold that data
- Score distributions, not just averages — a similar mean can hide very different tails
- Proxy variables: postcode, school name, employment gaps, career breaks, and language patterns can carry group differences without naming a group
- Job-relatedness: every criterion should connect to what the role actually requires. Ask whether you'd defend it out loud to the candidate
- Edge cases: non-native speakers, career changers, disabled candidates, older applicants, and resume formats the parser mishandles
How often, and by whom
Run a review before launch, again after any vendor model update, and on a fixed schedule afterward. Quarterly is workable for high-volume roles. Keep results in writing, including what you decided to change as a result. Small samples make group comparisons unreliable, so record the limits of what you can conclude instead of forcing a verdict.
A tested system is not a fair system. A tested, documented, and corrected system is on its way there.
Candidate Rights You Should Be Able to Honour
Compliance gets easier when you design around a short list of plain rights.
- To know — notice before the automated stage, not in the rejection email.
- To a human — a route to request that a person reviews a decision that matters.
- To an explanation — a brief description of the criteria used, in language a non-specialist can follow.
- To correct — a way to fix misparsed degrees, wrong dates, or duplicated records.
- To accommodation — an alternative format for tests and interviews, offered proactively rather than only on request.
- To deletion — data removed on a stated schedule, not held indefinitely in case it's useful.
- To an alternative — a non-automated path that doesn't disadvantage anyone who picks it.
Log every request. The pattern in that log will tell you more about your system than any vendor demo.
Write the Rules Into the Vendor Contract
Ask for the following before the pilot, not during a dispute:
- Audit or testing rights, and what documentation you'll receive
- Advance notice of model or logic changes that affect scoring
- A description of training data sources sufficient for your review
- Retention, deletion, and data location commitments
- A ban on using your candidate data to improve products sold to others
- Complaint handling with stated timelines, and breach notification
- An exit plan: export format, deletion confirmation, transition support
If a vendor can't describe how their scoring works in terms both HR and legal can follow, that tells you something too.
Keep Records You'd Be Willing to Show
Maintain a decision log: what the system recommended, what the human decided, and why the two diverged. Keep the job criteria in force at the time, bias review results, complaints, and the changes you made in response. Hold records long enough to answer a challenge, then delete them.
Rules on automated decision-making in hiring differ between countries and often between states or provinces, and they keep changing. Use this checklist as an operational starting point and take advice from an employment lawyer in your jurisdiction before you launch or materially change a system.
A 30-Day Plan You Can Actually Finish
- Week one: finish the inventory and name an accountable owner for each tool.
- Week two: draft the candidate notice and the accommodation offer, then test both on three colleagues outside HR.
- Week three: pull six months of funnel data, look at pass-through rates by stage, and write down two things worth investigating.
- Week four: add the missing clauses to your next renewal and set a date for the first bias review.
None of this needs a large team. It needs someone willing to write things down, ask uncomfortable questions, and keep asking them after launch. That habit, repeated, is what separates a defensible hiring process from a hopeful one.
Photo: Tima Miroshnichenko / Pexels
