A UK Recruitment AI DPIA, Mapped by Data Flow

Current to 21 September 2026. This is general information, not legal or employment advice.

A recruitment AI data protection impact assessment should follow candidate data through the hiring process—not start and end with a vendor questionnaire.

Under Article 35 of the UK GDPR, a controller must complete a DPIA before processing that is likely to create a high risk to people’s rights and freedoms. The assessment must describe the processing and its purpose, test necessity and proportionality, assess risks, and record safeguards (UK GDPR, Article 35).

AI recruitment commonly combines warning signs such as evaluation or scoring, innovative technology, decisions affecting access to a job, data matching and sometimes special-category data. The ICO says systematic and extensive automated evaluation producing significant effects always requires a DPIA; innovative technology such as AI also requires one when combined with another high-risk criterion (ICO, “When do we need to do a DPIA?”). If screening concludes that a DPIA is unnecessary, record the reasons rather than leaving no audit trail.

Start with the hiring decision, not the product name

Define the actual use case in one sentence:

The tool uses [specified candidate data] to produce [score, rank, recommendation or content], which [named people or systems] use at [hiring stage] to [take or inform an action].

“AI-assisted recruitment” is too broad. CV summarisation, candidate sourcing, interview transcription and automatic rejection involve different data, purposes and consequences. Map where automation changes the workflow; AI can draft, search, schedule, rank, score and recommend, but those functions do not carry the same risk.

Record whether an output merely informs a recruiter or decides who advances. Do not label a process “human reviewed” unless the reviewer has enough information, authority and time to disagree. The ICO’s 2026 recruitment work found that many participating employers were likely using solely automated, significant decisions and called for better transparency, consistent human involvement and bias monitoring (ICO, “Recruitment rewired”).

Build the DPIA around six data flows

Use one row per flow. A vendor’s system diagram can inform this table, but it cannot replace the employer’s assessment of its own configuration and hiring process.

Flow	Record in the DPIA	Risk questions to answer
1. Collection	Source, candidate fields, metadata, collection method and lawful basis	Is data supplied by the candidate, pulled from an ATS, bought, scraped or obtained from another platform? Would the candidate expect this use?
2. Enrichment and inference	Any generated traits, embeddings, classifications or inferred characteristics	Does the tool infer health, ethnicity, sex, personality or other sensitive information? Is that inference necessary and sufficiently accurate?
3. Scoring or generation	Inputs, transformation, output, confidence or error limits and intended use	What causes a score or recommendation to change? Is performance valid for this role, language and applicant population?
4. Decision and human review	Decision threshold, reviewer role, evidence shown, override power and escalation route	Can a person genuinely reverse the result? Are overrides recorded and applied consistently? What happens when data are missing or an accommodation is needed?
5. Disclosure and access	Employer users, vendor staff, subprocessors, hosting locations and international transfers	Who can see raw applications, recordings, scores and labels? Are access rights narrower than general administrator access?
6. Retention, deletion and reuse	Retention period for every input and output; deletion process; training or product-improvement use	Does deletion propagate to copies and subprocessors? Does the provider reuse candidate data for a shared model or unrelated sourcing database?

This level of detail matters. In its 2024 audits, the ICO found tools collecting excessive information, repurposing data from millions of online profiles, inferring characteristics without candidates’ knowledge, and using unclear controller–processor arrangements (ICO, AI in Recruitment Outcomes Report).

Test necessity before debating safeguards

For each flow, ask:

1. What precise hiring purpose does it serve? “Efficiency” is not specific enough. State whether the aim is faster scheduling, consistent transcription, identifying a required licence or ranking applicants.
2. Would less personal data work? Remove fields, recordings, inferred traits and free-text history that do not materially support the purpose.
3. Is AI necessary? Compare it with a structured form, deterministic eligibility rule, trained human review or a non-AI accessibility option.
4. Is the effect proportionate? A convenience for recruiters may not justify a material risk of wrongly excluding candidates.
5. Is each party’s role correct for each operation? A provider may be a processor for employer-configured screening but a controller for reusing applications to improve a shared model. The ICO specifically recommends defining controller, joint-controller or processor status for each processing operation and recording it in contracts and privacy information (ICO recruitment audit report).

Identify a lawful basis for each purpose, plus an Article 9 condition where special-category data is processed. A privacy notice does not itself create that basis; see the distinction between candidate consent and a privacy notice.

Write risks as candidate outcomes

Avoid entries such as “algorithm risk: medium.” Describe what can happen to a person, why, and at which flow.

Useful risk statements include:

• a qualified candidate is ranked below a threshold because their CV format is parsed inaccurately;
• speech transcription errors reduce an interview score for a candidate with an accent or disability;
• inferred demographic data are inaccurate, making fairness monitoring misleading;
• recruiters defer to a score without examining relevant evidence;
• a candidate cannot understand, correct or challenge data used in a decision;
• application data are retained or reused for model development beyond the stated hiring purpose;
• a breach exposes interview recordings, assessment answers or inferred traits;
• aggregate performance conceals worse error rates for a group or particular role.

Score both the likelihood and severity of harm to candidates, then identify the source of the risk. The ICO’s DPIA process expressly includes harms such as lost access to opportunities, discrimination, loss of control, financial loss and reputational damage (ICO, “How do we do a DPIA?”).

Convert each risk into a testable control

A control needs an owner, evidence, acceptance threshold and review date. For example:

• replace “monitor bias” with a pre-launch and periodic test broken down by relevant role, stage and group, with a named escalation threshold;
• replace “human in the loop” with the reviewer’s evidence, training, minimum review steps, override authority and quality sample;
• replace “minimise data” with an approved field list and a test showing disabled fields are neither transmitted nor retained;
• replace “allow challenges” with a candidate channel, response owner, review deadline and power to correct data or reconsider an outcome;
• replace “delete after recruitment” with separate periods for raw files, transcripts, features, scores, logs and backups, plus vendor deletion evidence.

The 2026 legal position also matters. The Data (Use and Access) Act 2025 broadened the lawful bases potentially available for significant automated decisions, while retaining the need for appropriate safeguards; special-category data remains more protected (ICO DUAA summary, updated 19 June 2026). The ICO expects employers using automated hiring decisions to monitor bias, explain the use to candidates, and provide a route to challenge and request human review (ICO, 31 March 2026). Do not rely on pre-DUAA summaries of Article 22 without checking current requirements.

Make the vendor produce evidence

Before contract signature, require answers and documents for the configured service—not a generic “responsible AI” page:

• field-level input and output specification;
• sources and permitted uses of training, testing and live candidate data;
• model purpose, limitations and prohibited uses;
• validation results relevant to UK recruitment and your intended roles;
• subgroup results, error definitions and sample sizes;
• retention and deletion schedule, including backups and subprocessors;
• security controls, incident terms and transfer arrangements;
• controller/processor analysis for every reuse;
• change logs and advance notice of material model or data-flow changes;
• support for access, correction, objection, complaint and human-review requests;
• the provider’s DPIA or risk assessment, while recognising that it does not discharge the employer’s responsibility.

The ICO recommends doing the recruitment DPIA before using the tool, ideally during procurement, and keeping it updated as processing and impacts evolve (ICO recruitment procurement questions).

Set a deployment gate

The sign-off should state one of four outcomes: proceed; proceed only after listed controls are verified; redesign or narrow the use; or do not proceed.

Record the DPO’s advice where the organisation has one, candidate or representative consultation, unresolved disagreements, control owners and review triggers. Triggers should include a new data source, model version, role family, decision threshold, subprocessor, retention use, reported disparity or candidate complaint.

If high residual risk remains after mitigation, consult the ICO before processing. The ICO also says the DPIA’s actions must feed back into the project plan and the assessment must remain under review (ICO DPIA process). As of 21 September 2026, some ICO DPIA and AI guidance pages remain marked as under review following the DUAA, so check the current regulator guidance and legislation at sign-off rather than treating this workflow as a substitute for counsel.